技术开发 频道

NHibernate和Entity Framework 4优劣论

  【IT168 评论】最近,Oren Eini(也被称为Ayende Raheim)发表了一个帖子,从而引发了关于NHibernate和Entity Framework 4.0各自优点和功能的讨论,而这二者都是基于.NET的对象/关系映射框架。对此讨论进行了深入的探究,以了解其中提到的观点。

  Rahien是NHibernate项目的成员之一,他对NHibernate和Entity Framework 4(EF)做了简要的比较。在称赞EF 4相比EF1.0所作出的进步之后,Rahien列举了他认为使得NHibernate成为更好的ORM解决方案的特性:

  ·批量写入——我们可以配置NHibernate,使其对数据库进行批量写入,从而在你需要向数据库中写入多个指令的时候,NHibernate只需要与其进行一次交互,而不需要在每个指令的执行过程中都要访问数据库。

  ·批量读/多重查询特性——NHibernate使你可以在与数据库的一次交互过程中批量执行多个查询,而不需要在独立的交互过程中执行每个查询。

  ·批量的集合加载——当你延迟加载集合的时候,NHibernate能够找到其它相同类型而没有载入的集合,然后只对数据库进行一次访问,就把它们全部载入。这种方法很好,因为这样就可以避免处理SELECT N+1的问题。

  ·带有lazy="extra"的集合——额外的延迟意味着NHibernate会适应你可能在集合之上所要执行的操作。这也意味着 blog.Posts.Count不会强行载入整个集合,而是创建“select count(*) from Posts where BlogId = 1”的指令,然后blog.Posts.Contains() 会类似地执行单独的查询,而不需要付出将整个集合都载入到内存中的代价。

  ·集合过滤器和分页集合——这让你能够在实体集合上定义附加的过滤器(包括分页!),这意味着你可以很容易地对blog.Posts集合进行分页浏览,而不需要将所有的内容都载入到内存中。

  ·二级缓存——管理缓存很复杂,之前我曾经谈过这为什么很重要,所以现在我将跳过它。

  ·调整——当你需要某些框架没有提供的功能的时候,这就显得很重要了。使用NHibernate,几乎在所有的情况下,你都有扩展点,但如果使用的是EF,你是完全并且绝对做不到的。

  ·集成和扩展性——NHibernate有大量扩展项目,像NHibernate Search、NHibernate Validator,NHibernate Shards等等。而在EF中不仅不存在这样的项目,而且大多数情况下也无法编写这样的项目,因为EF没有任何可以使用的扩展点。

  Rahien也提到了使用EF 4的优势:

  ·EF 4.0比当前的NHibernate实现拥有更好的Linq提供程序。这也正是NHibernate正在积极改进的地方,NH 3.0将会弥补这个问题。

  ·EF属于微软。

  作为NHibernate项目知名的贡献者,Rahien的帖子引发了相当数量的正反两方面的响应。一位名叫tobi的读者对NHibernate错误消息的缺少提出了抱怨:

  我只使用过NHibernate几个小时,对于我来说,手动创建域的类和映射(我使用了FluentNHibernate )的过程需要太多手动的工作,并且错误信息不是很好。这是我认为相比而言EF 4比较好的地方。

  Roy对于错误信息和文档有着矛盾的心情:

  EF的一个额外的优势在于文档组织得更好,并且错误信息能够更清楚地描述问题。

  尽管如此我还是更喜欢NH,但是一旦你遇到问题,那么就需要浏览大量的博客来解决。相反,它的优势在于有很多人你可以请教。

  Jimmy Bogard赞赏NHibernate的缺陷修正过程,这使得它更有吸引力:

  NH的另一个主要优势在于它是开源软件。这些年来我多次需要给NH打补丁,以修正缺陷或者添加我所需要的功能。如果使用的是EF,我是不能做这些的。

  Alex Yakunin参与了另一个ORM工具ORMBattle.NET测试套件的创建工作,他抱怨说:

  我想你可以很清楚地发现,在这里只显示了NHibernate的优点。而根本没有涉及到它的缺点——即便是你提到的关于LINQ提供程序的说法也和事实相去甚远;另一个众所周知的问题是EF支持变更跟踪,而NH不支持,这在很多情况下会很大程度上影响性能(事实上,你应该完全忘记NH中的特定情况 ——那是“有意地”)。

  Radenko Zec对单元测试和设计器的功能进行了比较:

  我想NHibernate最大的优势在于它能够更好地支持单元测试。EF 4并非为测试而设计,因此很难基于EF 4为某些自定义的解决方案编写单元测试。

  另一方面,EF 4拥有很好的设计器(对于真实世界中的大型项目,这是你所需要的最重要的东西),还有基于该设计器的POCO T4模板。我想现在是你应该开始考虑为NHibernate建立自己的设计器,而不是拒绝设计器和代码生成器的时候了。如果社区需要NHibernate 的设计器,那么就给他们好的设计器。第三方的设计器和EF4的设计器相差甚远,可能除了LLBGEN 3还好一些,但是它还没有发布,而且不是免费的。

  Frans Bouma是另一个ORM工具LLBLGenPro的作者,当说到文档时他指出NHibernate在该方面非常欠缺。

  EF比NH好的地方就在于文档、一致的示例以及在每次开发者大会上发表的大量的传播演讲,还有日夜不停发表的文章……NH应该在这个问题上吸取教训(并且请不要找借口,它确实应该在文档方面吸取教训。如果你想要知道在那上面应该吸取多大的教训,那么请现在就去查看为_N_hibernate提供的 DDL SQL生产文档,看它有多伟大,甚至能够产生……java类。嗯?),同时还有很多可选择的方法,那真的不是它所拥有的优势。

  Felix建议采用组合式的解决方案:

  不要相信某人所说的“OR/M是编码的越南战场”,NH是老兵,而EF是年轻的新兵。不幸的是微软不支持开源,如果可以的话,事情会变得更容易:使用微软提供的设计器和集成工具,使用NH作为OR/M,这会是高生产力的解决方案。

  讨论所呈现出来的一般共识是,尽管Entity Framework拥有更好的LINQ提供程序、文档,并且是由微软所支持的,但NHibernate具有大量Entity Framework 4.0所不具备的特性,像批量读/写、“额外的”延迟、集合过滤器、调整等等。关于这个讨论你的看法如何呢?

0
相关文章