刚看了一篇文章，本来想跟个贴追捧一下ORM，最后还是决定单独写一个Post，以充分发挥“对台戏”的效果。
先说明一点，我其实不喜欢ORM这个概念，我觉得这个概念并不十分优雅，尽管非常普遍。
什么是大型软件
我不知道原文中的大型软件是什么概念。不过我心目中的概念是结构、功能和逻辑都足够复杂，并发量很大，甚至需要多台服务器进行负载平衡，且一般有一定的应用集成需要的、需要大量人员参与构建的软件。这样的软件其价值非常可观。通常大家都与“企业级应用软件”的概念相互套用。所以，我下文中用“企业级应用软件”来替换原文中的“大型软件”。
现实中的解决方案
在Java的世界里，企业级应用软件自然就使用J2EE方案。比较通用的J2EE解决方案是采用EJB，并采用JDO之类的技术做持久化。由于EJB固有的缺陷，现在用EJB的人越来越少了。原因大家看看Rod Johnson的《J2EE Development without EJB 》应该自然就明白了。但是没有人会推荐在J2EE中直接使用Statement来直接进行持久化，或者对Statement进行一些简单的封装做一个所谓的“通用的持久层”。当然，Hibernate取得了巨大的成功，所以Hibernate3就自然成了JSR的一部分。如果不是因为企业应用的需要，Hibernate其实是没有市场的。
回到.net里。若干年前，当我听说Microsoft打算在SQL Server 2005中实现ORP(Objective-Relational Persistence)的时候，我兴奋了一阵，但事实上最后Microsoft并没有实现这个诺言，就象Microsoft也没有向业界交付Object-Spaces一样。这可能是对ORM持保守态度者的主要依据来源。大家都是通过最原始的方案或者简单的封装(包括企业库中的DAAB)来实现数据访问。这些Helper类被渗透到应用程序的每一个部分，甚至完全耦合。
就象J2EE当年的景象一样，大家都在等待.Net中的Hibernate，在等待中纷纷动手做自己的ORM。在这个过程中冒出来一堆优秀的、商业化的框架，例如ECO、XPO、DataObjects等等。这些框架设计精妙，性能优异。当然也出现了很多优秀的开源框架，例如Neo。它们都各有千秋，有一些功能强大，但结构复杂。有一些功能较弱，但结构简单且易于使用。
Microsoft已经让我在ORP上面失望过一次。我不知道会不会在DLinq上再让我失望一次。我不象某些人那样乐观。
持久层的意义
持久层其实只是一个应用程序中很小的一部分，在应用程序中的地位远不象某些人所描述的那样关键。如果你的设计中系统的分层非常好的话，只有业务逻辑才需要ORM，因为表现层应该是完全不关心持久层的。相反，如果你的系统不分层，ORM的确一点意义也没有。所以，其实小的系统根本不需要ORM。这些系统往往两三个人就可以完成，他们可以直接在页面上使用Native的SQL语句访问数据。呵呵，在Microsoft平台，大量的开发人员都是这么过来的。
但是企业级应用，不分层是无法完成的。每个细小的功能都需要分给三个或者更多的人来完成。如果不分层，则完全无法控制。如果分层的话，在业务逻辑层甚至表现层再直接访问数据库就成了不可思议的事情。这时候，ORM就成了你不多的选择之一。
随着系统越来越庞大，系统对于可维护性、可集成性、可扩展性、可测试性的需要也越来越强，对分层的需要也就越来越迫切。其中任何一个特性的需要，离开ORM都无法很好地实现。
ORM的哪些方面被人指责
性能。大多数人想当然地认为ORM都是性能拙劣，仅仅因为他们用过了NHibernate。我没有用过NHibernate，我无法评价NHiberbate的性能。但是我知道，ORM对性能的影响是极其有限的，如果造成性能问题，往往都是因为使用不当。即使你直接使用ADO.NET也一样会冒出性能问题来。相反，由于Cache的原因，ORM事实上通过空间的牺牲换取了大量数据库访问性能的提升。当然，这要求框架本身实现了这一功能，并且正确地使用。相反，没有ORM的Helper是很难实现Cache的。
使用难度大。我不知道大家如何看待Hibernate的使用。最初的、干净的、不带任何第三方工具的Hibernate完全依靠手工编撰映射文件和POJO代码。即使如此还是有大量的人来使用。而现在的ORM框架多数都提供了这样的工具，帮助你很好地利用框架提供的功能。其实除了对面向对象方面知识和思想的要求，使用ORM后的业务对象来使用。因为通过ORM来编写业务逻辑几乎比任何一种Helper的方式都简单。相反十年前撰写和调试存贮过程的回忆每每让我如恶梦一般。
不稳定。其实持久层是一个很局部的东西，整体上并不复杂。只要有足够的测试就可以保证框架本身的稳定性。如果框架本身稳定，不太可能因为持久层的原因导致系统不稳定。
ORM到哪个程度最合适
大量的开发人员实现了自己的简单的持久层。如果太简单，没有什么意义。如果太复杂往往并不实际。首先，必须真的提升了开发效率，必须切实解决了团队开发中的耦合问题。其次，具有足够的可扩展性。最后，必须提供基本的工具。
结论
不要再提“大型系统”不适合使用ORM的说法了，要知道，ECO就是专门针对“大型系统”的。相反，小系统才完全没有必要使用ORM。