园内ORM讨论的经典文章及评论

考虑整合一个ORM框架，顺手把找到的资料索引一下，供大家参考。

NET开源项目介绍及资源推荐：数据持久层 
对.net的常见ORM有简略但不错的说明。一个好的总结和指引。

ORM之硬伤 
是对“ORM的缺点论”进行反驳的一篇最言之有物的一个帖子。楼主认为ORM的真正问题是国内.net程序员的OO功力不够。帖主尤其强调在“性能及复杂查询”的问题上认为是没有问题。
robin:个人认为“性能及复杂查询”是否有问题还有待验证。所以我还是推荐复杂查询还是自己扩展DBHelper来做，直接有效。

O/R Mapping，陷阱还是苹果？ 
这里对ORM的反思较为深入，使用ORM之前，值得参考考虑一下。

大型软件开发与ORM构架
帖子对选用ORM的前期预研、验证要求给出了一些指引。对企业使用新技术的预研、验证，也即新技术的风险控制，有不错的说明。
robin:确实大家不要听到ORM是个好东西就乱用，应该要经过严谨的验证、考虑才能用。

再次小结领域模型的种种观点 
这个帖子是在领域模型的设计方面讨论最深入的一个中文帖子。非常值得一看。
主要是讨论了”贫血模型“的经典问题。
给出了实际例子。注意其中的”rich domain object“里，domain是不依赖于DAO的。
robin:
1.感觉用NH的弟兄，大多都是写成了”贫血领域模型“，也就是实体对象只有数据没有动作。(这也是我有疑惑，目前还不能定的问题)。从OO的本意(对象=”数据+动作“的封装)来说，这当然不是一个好的设计。但是用了ORM后，如果要对象包括动作，domain object就要访问DAO，这又导致了双向依赖问题。
2.目前在分层设计上，仍存在疑惑。有待验证。

NHibernate下持久化类的两种设计，哪种更好一些？ 
讨论”NHibernate下持久化类的设计时关于关于对象的操作和数据是否应该剥离的问题“，给出了两种方式下的实现，值得参考。里面的回复里的讨论也颇有价值。
robin:贫血领域模型用的就是第一种方式。Castle ActiveRecord用的就是类似第二种方式。

使用NHibernate的系统体系结构
帖子给出了一种比较”传统“的NH的分层设计，有一定的参考价值。
robin:UI引用Domain、Domain引用NH DAO,都是有争议的。

Enterprise Persistence Design
帖子对ORM的意图作了逐步渐进的分析说明，对service/domain/DAO的分层设计作了原理上的讨论，值得推荐。
robin:依据这个理论做出来的分层设计，基本上就是hibernate的经典写法：贫血领域模型。但是帖主强调的” 不该做的不做(Separate persistence from business）、该做的要做(Implement business）、自己独力不能做的交给别人做(Delegate, Façade)”，很有意义(注意理解英文，更能体现本意)。“再次小结领域模型的种种观点”的弟兄认为：设计持久化的动作就放在service,不涉及持久化又适合放在domain的就放在domain。这个观点值得参考，但是有待验证实际效果怎样。讨论：是否可以省略DAO,直接在service调用NH的接口，完成持久化对象的职责？（不过这样就类似事务脚本的写法了）

从我的亲身经历来说说我对ORM的一些看法 
帖子认为”先有对象再映射到数据库才是使用ORM的正途。“。认为目前.net社区的弟兄的关于ORM的争论根源，就是来自于大家是先R(数据库)再O(对象），这个根本性的错误应用方法，也正是导致”ORM的缺陷“的根源。
robin:这个观点值得考虑、分析。但“先O再R”在实际开发是否真的适用，有待验证。

O/R Mapping乱弹 
帖子提出了”先O再R“还是”先R再O“的问题。认为ORM的价值在于可以支持你”从面向对象的角度分析考虑问题“。即先建立领域模型(O)，再通过ORM直接导出生成表设计(R)。
robin:这似乎是提出了ORM的”终极价值“。但感觉缺乏验证(跟贴的弟兄也提出质疑)。我个人也存在怀疑，先O再R是否真正可行。毕竟数据库设计本身就是一个非常专业、需要一定功力的事情，一个好的表设计是需要功力的，尤其是在性能提升方面。先O是否能直接映射生出本应该精心设计的表？存疑。更实际的做法可以是”先用OO作领域模型设计，再参考领域模型，完成数据库设计“。在数据库设计阶段，会应用一些专业的设计技巧，这个估计是对象所体现不了的。

O/R Mapping再乱弹
”ms注重数据，java注重动作(逻辑)“，这个帖子解释了为什么在.net上用ORM会有这么多困惑：因为ms平台上一向都是不OO实现的，一向都是表模块方式、事务脚本方式。
robin:一语惊醒梦中人，确实如此。微软平台的弟兄们，大多就算用c#这样的OO语言，也是将class当一个事务脚本类来写的。这么多年，一样写出了不少应用。
我个人就觉得是否需要使用ORM，是否需要转向真正的OO的写法，是需要根据本公司的具体情况作实际验证的--是否能提高效率，是否能提升设计？有没有可以胜任OO设计的设计人员？开发组成员的OO思维的学习成本有多高？需要考虑一个投入及收益的问题，不能为了OO而OO，为了ORM而ORM。

结束无谓的讨论吧
这位弟兄试图结束ORM的争论。并认为如果你的写法根本不是OO，那就没必要讨论ORM了。
robin:这又牵扯回”国内.net程序员OO功力不够“的问题了。确实是有这个问题。但是个人认为就算OO功力不够，ORM也是有意义的，至少可以将它当一个快速开发的代码生成器来用(如Castle ActiveRecord)。另外也确实是，用ORM，OO，其实对团队的设计能力有较高的要求，如果设计能力跟不上，反而不如直接用”表模块“、事务脚本的写法更有效。

分布式应用架构中的数据传输对象（DTO）
对DTO的常见实现方式及其优劣点，作了不错的描述，值得参考。
.Net 2.0: Entity as DTO vs Dataset as DTO / Xml Serialization vs JSON Serialization
这里有实际的测试。并认为dataset是一个好的DTO方案。
PO,VO,DTO....
PO,VO,DTO的一点讨论.
robin:个人倾向与用datatable和标量。最好不要再自己写dto对象，序列化等麻烦。有弟兄说在“贫血领域模型”里，可以将domain object当DTO用(不含持久化职责的Domain Object)，可以参考，但总觉得domain object不应暴露给UI，应用Service隔开才是好的设计。