最近,Oren Eini(也被称为 Ayende Rahein)发表了一个帖子,从而引发了关于 NHibernate 和 Entity Framework 4.0 各自优点和功能的讨论,而这二者都是基于.NET 的对象 / 关系映射框架。InfoQ 对此讨论进行了深入的探究,以了解其中提到的观点。
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 所不具备的特性,像批量读 / 写、“额外的”延迟、集合过滤器、调整等等。关于这个讨论你的看法如何呢?
评论