再老调重弹一个例子（我的ORM用了多少年了，我最关注的是把握好重量与灵活之间的平衡——因为我很明确我的ORM的目的，不曾偏离）：
无论有没有ORM，无论你是OO分析设计和开发还是仅仅 object based，
首先静下心来反思一下，看看自己做分析设计的时候，如何设计出数据结构的？
方法一：
先用oo的方法分析业务领域，建模，然后根据最后的 class diagrames 结合一定的数据库设计策略、优化策略等来建表
方法二：
管它三七二十一，一边考虑业务模型，一边建表，之后再用 ORM 或者手工编写表对应的 model 类
如果是方法一，恭喜你，只需要一个恰当的 ORM 工具，之后建表时在数据库设计策略、优化策略等基础上结合这一工具对建表的一些特殊要求和策略，今后你使用 ORM 会比较轻松。
如果是方法二，也没问题——但不要强求ORM能够自动理解如何将你的表转换为理想的对象模型——能够得到 Model Class 不错了。
有人或许跳出来说：我就是先建表也没影响后面建对象模型！是的，那是你运气比较好，或者经验比较丰富，默认的在建表的时候已经结合 OO 策略进行了一定的考虑。但如果以后的设计能够更加“清醒”，有意识地这么做，效果一定会更好。
ORM 究竟是什么？代码生成工具？
基于 某种 数据访问/持久化模型 甚至运行在某种框架基础上的，结合了一定的O-R或R-O映射关系规则及其编辑器的，可能还加了代码生成器的工具集合！
也就是说，离开了这些工具、编辑器，它的核心是一种数据访问/持久化模型，配合一定的O-R/R-O映射实现策略。
所以，流行的 ORM 基本都是这两种路线：
1、轻量级：依赖某种策略或策略+用户配置文件自动从数据库创建Class，以生成代码为主。好不好用，取决于你的建表与OO平衡的水平如何，策略配置水平如何；
2、重量级：又有两种。一种，希望一次性解决根本问题，提供用OO的方式设计的工具甚至语言，然后自动建表；另外一种，把ORM往framework方向扩展——严格来说应该是framework，ORM是其中的一个主要功能。
我个人倾向：学习和研究，走HQL类路线；工作中解决实际问题，走轻量级路线，以代码生成为主。
然后，用在HQL等学习中的收获——如何协调好OO和数据结构设计之间的关系——不断用在使用轻量级的ORM工具之前（也就是说用来建表），一则实战这些经验，二则从ORM之外弥补轻量级ORM的不足。
为何？重量级ORM这条路不是走不通，是非你我之辈能够简单理解和跟上的。
学习要继续，生活也要继续。
于是，我自己的 ORM 目标很明确：
1、保持轻量级
2、精简：仅针对数据访问层，以确保最大的灵活性——不是ORM提供的功能灵活，而是架构灵活，使用方式灵活；
3、支持事务、支持“热插拔”（不喜欢这个词，但很多人喜欢这么说）更换不同的数据库，甚至持久化方式，支持多个库（暂时把跨库事务交给业务逻辑层）
4、具体语言无关：尽量不使用语言特性，支持ASP、JSP、PHP，VB，VC，C#等等。如果有必要，为特别的版本定制模板即可
5、结合代码生成工具使用，但也可以不用：本来的目的就是为了提高开发效率，提高质量（生成的代码不必重复测试）。而核心是数据访问模型，是工作方式，手写代码又如何？
6、架构灵活：因为精简到模型级别，不同语言下可以实现。那么，我把针对不同语言的部分分离出来交给代码生成器甚至模板解决。而使用的时候，就可以根据需要在不同模板中扩展自己的一些特殊需求（例如，有项目大量依赖DataSet，那就为Model模板加入Convert2DataSet()方法）。从而达到既轻量，又灵活的目的。
于是，在日常工作中，逐渐积累一些模板和DAC类（不同DAC能够解决不同的数据库服务器、不同的数据访问方式如是否通过存储过程、不同的持久化方式）即可。
我心态很平稳，因为我的目的很明确
朋友们，你呢？
无论有没有ORM，无论你是OO分析设计和开发还是仅仅 object based，
首先静下心来反思一下，看看自己做分析设计的时候，如何设计出数据结构的？
方法一：
先用oo的方法分析业务领域，建模，然后根据最后的 class diagrames 结合一定的数据库设计策略、优化策略等来建表
方法二：
管它三七二十一，一边考虑业务模型，一边建表，之后再用 ORM 或者手工编写表对应的 model 类
如果是方法一，恭喜你，只需要一个恰当的 ORM 工具，之后建表时在数据库设计策略、优化策略等基础上结合这一工具对建表的一些特殊要求和策略，今后你使用 ORM 会比较轻松。
如果是方法二，也没问题——但不要强求ORM能够自动理解如何将你的表转换为理想的对象模型——能够得到 Model Class 不错了。
有人或许跳出来说：我就是先建表也没影响后面建对象模型！是的，那是你运气比较好，或者经验比较丰富，默认的在建表的时候已经结合 OO 策略进行了一定的考虑。但如果以后的设计能够更加“清醒”，有意识地这么做，效果一定会更好。
ORM 究竟是什么？代码生成工具？
基于 某种 数据访问/持久化模型 甚至运行在某种框架基础上的，结合了一定的O-R或R-O映射关系规则及其编辑器的，可能还加了代码生成器的工具集合！
也就是说，离开了这些工具、编辑器，它的核心是一种数据访问/持久化模型，配合一定的O-R/R-O映射实现策略。
所以，流行的 ORM 基本都是这两种路线：
1、轻量级：依赖某种策略或策略+用户配置文件自动从数据库创建Class，以生成代码为主。好不好用，取决于你的建表与OO平衡的水平如何，策略配置水平如何；
2、重量级：又有两种。一种，希望一次性解决根本问题，提供用OO的方式设计的工具甚至语言，然后自动建表；另外一种，把ORM往framework方向扩展——严格来说应该是framework，ORM是其中的一个主要功能。
我个人倾向：学习和研究，走HQL类路线；工作中解决实际问题，走轻量级路线，以代码生成为主。
然后，用在HQL等学习中的收获——如何协调好OO和数据结构设计之间的关系——不断用在使用轻量级的ORM工具之前（也就是说用来建表），一则实战这些经验，二则从ORM之外弥补轻量级ORM的不足。
为何？重量级ORM这条路不是走不通，是非你我之辈能够简单理解和跟上的。
学习要继续，生活也要继续。
于是，我自己的 ORM 目标很明确：
1、保持轻量级
2、精简：仅针对数据访问层，以确保最大的灵活性——不是ORM提供的功能灵活，而是架构灵活，使用方式灵活；
3、支持事务、支持“热插拔”（不喜欢这个词，但很多人喜欢这么说）更换不同的数据库，甚至持久化方式，支持多个库（暂时把跨库事务交给业务逻辑层）
4、具体语言无关：尽量不使用语言特性，支持ASP、JSP、PHP，VB，VC，C#等等。如果有必要，为特别的版本定制模板即可
5、结合代码生成工具使用，但也可以不用：本来的目的就是为了提高开发效率，提高质量（生成的代码不必重复测试）。而核心是数据访问模型，是工作方式，手写代码又如何？
6、架构灵活：因为精简到模型级别，不同语言下可以实现。那么，我把针对不同语言的部分分离出来交给代码生成器甚至模板解决。而使用的时候，就可以根据需要在不同模板中扩展自己的一些特殊需求（例如，有项目大量依赖DataSet，那就为Model模板加入Convert2DataSet()方法）。从而达到既轻量，又灵活的目的。
于是，在日常工作中，逐渐积累一些模板和DAC类（不同DAC能够解决不同的数据库服务器、不同的数据访问方式如是否通过存储过程、不同的持久化方式）即可。
我心态很平稳，因为我的目的很明确
朋友们，你呢？