国内(比较早)
2008-10-14 16:58 Karron Qiu
目前看起来 LinQ2SQL 和Linq2Entities 在ORM范围内还没有达到NH的高度, 比如延迟加载, 关系映射, Domain层的纯洁度上面离NH还差得远. 为了达到可视化的设计, 引入的丑陋的后台代码或者配置信息, 简直就是据人以千里之外, 完全没办法进行真正的领域方法设计, 虽然我也很讨厌NH的xml配置, 但是可以用castle的AR的attribute来弥补, Linq系ORM唯一值得自豪的是Linq的语法实在是太爽了. 比较期待Linq2NH项目的成熟.
2008-10-18 08:57Gray Zhang
@Karron Qiu
Linq to SQL的配置可以非常非常干净，纯XML配置绝不会比NH差
EF的关系映射肯定比NH强
但是NH集合了2个的优点，所以我还是选择NH
2008-10-23 16:39 Karron Qiu
@Gray Zhang
Linq2SQL的xml配置我倒没有去看过, 不过我看过EF的. EF的似乎把配置信息分成了3个文件, 实在是比较复杂, 对于像我这样连NH这样可读性还不错的xml我都不喜欢, 那么对于EF这种, 我实在是无爱. 因为领域对象, 很多时候是需要自己去调整的, 特别是多对多, 一对多这样的, 而不是直接从数据库生成就可以了. 如果配置文件比较复杂, 实在是难以下手. 我个人也比较反对用代码生成工具. 我现在对象基本都是手写. VS2008+Resharper+自己定义一些snippet, 写起来还是很快的.
所以我现在的开发平台是NH+Castle的Attribute+自己写的通用IRepository+具体的定制的Repository+Castle的validator, 中间层用Castle的ATM来管理事务, Castle的Windsor来管理业务对象, 再加上自己写了些Intercepter去做日志什么的, 感觉还是不错.
其实直接Castle的AR也不错, 但是由于AR混杂了大量的静态方法, 以及数据库相关的方法, 导致有的时候模型继承等等特性不是很好用. 所以建议不要继承AR的基类.
另外你提到EF的关系映射肯定比NH强, 我想听听原因, EF我并不很熟. EF的网铺的很大, 视野也比NH高, 这个是肯定的. 但是在ORM层次上, 我觉得NH还是比EF好很多.
另外, 对于ORM, 很多人总是质疑性能. 但是我觉得, 应该不需要去怀疑NH的成熟度. 有人说手写SQL不说比ORM一定快, 至少速度也差不多. 但是同样的话语以前也有, 只不过是说的汇编语言和c语言, 后来, 又是c++和.net进行比较. 但是现在为什么很多人去选择高级语言, 原因是开发效率高. NH这样的ORM, 由于封装层次较高, 用得不好的话, 是可能会性能低. 但是如果注意了Lazy Loading, Query Strategy什么的,尽量避免N+1什么的, 这样性能并不差. 更何况, 可以使用Second Level Cache之类的去提高性能. 现在Linq2SQL之类的MS的官方ORM出来之后, 估计会更多人使用ORM了, 很少有人会去走手写ADO.NET的老路了.
国外
年初的时候，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的帖子引发了相当数量的正反两方面的响应。
其他技术人员对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所不具备的特性，像批量读/写、“额外的”延迟、集合过滤器、调整等等。
关于这个讨论你的看法如何呢?
参考资料:
http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx