NHibernate和Entity Framework论
最近，Oren Eini(也被称为AyendeRaheim)发表了一个帖子，从而引发了关于NHibernate和EntityFramework4.0各自优点和功能的讨论，而这二者都是基于.NET的对象/关系映射框架。对此讨论进行了深入的探究，以了解其中提到的观点。
Rahien是NHibernate项目的成员之一，他对NHibernate和EntityFramework4(EF)做了简要的比较。在称赞EF4相比EF1.0所作出的进步之后，Rahien列举了他认为使得NHibernate成为更好的ORM解决方案的特性：
·批量写入——我们可以配置NHibernate，使其对数据库进行批量写入，从而在你需要向数据库中写入多个指令的时候，NHibernate只需要与其进行一次交互，而不需要在每个指令的执行过程中都要访问数据库。
·批量读/多重查询特性——NHibernate使你可以在与数据库的一次交互过程中批量执行多个查询，而不需要在独立的交互过程中执行每个查询。
·批量的集合加载——当你延迟加载集合的时候，NHibernate能够找到其它相同类型而没有载入的集合，然后只对数据库进行一次访问，就把它们全部载入。这种方法很好，因为这样就可以避免处理SELECTN+1的问题。
·带有lazy=extra的集合——额外的延迟意味着NHibernate会适应你可能在集合之上所要执行的操作。这也意味着blog.Posts.Count不会强行载入整个集合，而是创建“selectcount(*) from Posts whereBlogId =1”的指令，然后blog.Posts.Contains()会类似地执行单独的查询，而不需要付出将整个集合都载入到内存中的代价。
·集合过滤器和分页集合——这让你能够在实体集合上定义附加的过滤器(包括分页!)，这意味着你可以很容易地对blog.Posts集合进行分页浏览，而不需要将所有的内容都载入到内存中。
·二级缓存——管理缓存很复杂，之前我曾经谈过这为什么很重要，所以现在我将跳过它。
·调整——当你需要某些框架没有提供的功能的时候，这就显得很重要了。使用NHibernate，几乎在所有的情况下，你都有扩展点，但如果使用的是EF，你是完全并且绝对做不到的。
·集成和扩展性——NHibernate有大量扩展项目，像NHibernateSearch、NHibernateValidator，NHibernateShards等等。而在EF中不仅不存在这样的项目，而且大多数情况下也无法编写这样的项目，因为EF没有任何可以使用的扩展点。
Rahien也提到了使用EF 4的优势：
·EF4.0比当前的NHibernate实现拥有更好的Linq提供程序。这也正是NHibernate正在积极改进的地方，NH3.0将会弥补这个问题。
·EF属于微软。
作为NHibernate项目知名的贡献者，Rahien的帖子引发了相当数量的正反两方面的响应。一位名叫tobi的读者对NHibernate错误消息的缺少提出了抱怨：
我只使用过NHibernate几个小时，对于我来说，手动创建域的类和映射(我使用了FluentNHibernate)的过程需要太多手动的工作，并且错误信息不是很好。这是我认为相比而言EF4比较好的地方。
Roy对于错误信息和文档有着矛盾的心情：
EF的一个额外的优势在于文档组织得更好，并且错误信息能够更清楚地描述问题。
尽管如此我还是更喜欢NH，但是一旦你遇到问题，那么就需要浏览大量的博客来解决。相反，它的优势在于有很多人你可以请教。
Jimmy Bogard赞赏NHibernate的缺陷修正过程，这使得它更有吸引力：
NH的另一个主要优势在于它是开源软件。这些年来我多次需要给NH打补丁，以修正缺陷或者添加我所需要的功能。如果使用的是EF，我是不能做这些的。
Alex Yakunin参与了另一个ORM工具ORMBattle.NET测试套件的创建工作，他抱怨说：
我想你可以很清楚地发现，在这里只显示了NHibernate的优点。而根本没有涉及到它的缺点——即便是你提到的关于LINQ提供程序的说法也和事实相去甚远;另一个众所周知的问题是EF支持变更跟踪，而NH不支持，这在很多情况下会很大程度上影响性能(事实上，你应该完全忘记NH中的特定情况——那是“有意地”)。
Radenko Zec对单元测试和设计器的功能进行了比较：
我想NHibernate最大的优势在于它能够更好地支持单元测试。EF4并非为测试而设计，因此很难基于EF4为某些自定义的解决方案编写单元测试。
另一方面，EF4拥有很好的设计器(对于真实世界中的大型项目，这是你所需要的最重要的东西)，还有基于该设计器的POCOT4模板。我想现在是你应该开始考虑为NHibernate建立自己的设计器，而不是拒绝设计器和代码生成器的时候了。如果社区需要NHibernate的设计器，那么就给他们好的设计器。第三方的设计器和EF4的设计器相差甚远，可能除了LLBGEN3还好一些，但是它还没有发布，而且不是免费的。
FransBouma是另一个ORM工具LLBLGenPro的作者，当说到文档时他指出NHibernate在该方面非常欠缺。
EF比NH好的地方就在于文档、一致的示例以及在每次开发者大会上发表的大量的传播演讲，还有日夜不停发表的文章……NH应该在这个问题上吸取教训(并且请不要找借口，它确实应该在文档方面吸取教训。如果你想要知道在那上面应该吸取多大的教训，那么请现在就去查看为_N_hibernate提供的DDLSQL生产文档，看它有多伟大，甚至能够产生……java类。嗯?)，同时还有很多可选择的方法，那真的不是它所拥有的优势。
Felix建议采用组合式的解决方案：
不要相信某人所说的“OR/M是编码的越南战场”，NH是老兵，而EF是年轻的新兵。不幸的是微软不支持开源，如果可以的话，事情会变得更容易：使用微软提供的设计器和集成工具，使用NH作为OR/M，这会是高生产力的解决方案。
讨论所呈现出来的一般共识是，尽管EntityFramework拥有更好的LINQ提供程序、文档，并且是由微软所支持的，但NHibernate具有大量EntityFramework4.0所不具备的特性，像批量读/写、“额外的”延迟、集合过滤器、调整等等。关于这个讨论你的看法如何呢?
posted @ 2012-05-13 16:29 江湖海 阅读(14) 评论(0) 编辑
