只有企业级项目才特别需要使用ORM

刚看了一篇文章,本来想跟个贴追捧一下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。

posted @ 2007-01-04 21:56  双鱼座  阅读(17547)  评论(20编辑  收藏  举报