MS实体框架VS NHibernate及其派生的贡献(FluentNHibernate,Linq for NHibernate)

Question

我刚刚阅读了有关Entity Framework 4(实际上是版本2)的这篇文章.

实体框架似乎比其首次发布提供了巨大的改进.因此,我从来没有在任何项目中使用EF,因为我觉得EF与NHibernate相比还不够成熟.

NHibernate及其目前对FluentNHibernate和Linq for NHibernate的贡献由Ayende Rahien提供

我的感觉是,当NHibernate的第二版出现时,微软只是试图获得有利于NHibernate的地形.不过,我的担忧是以下(不是特别有序):

• EF4往往不那么XML冗长吗？
• EF4是否与SQL Server以外的基础数据存储兼容？
• 使用EF4代替FluentNHibernate或NHibernate本身有什么好处？

NHibernate是一个很棒的工具,我想每个人都同意.由于其前身Hibernate,我们可以轻松找到文档和教程以及示例应用程序以熟悉它.FluentNHibernate不是这种情况.特别是根据我正在进行的项目,我要求我进一步调查NHibernate及其选项(例如FluentNHibernate),以便记录NHibernate和FluentNHibernate技术的使用规则和最佳实践.因此,作为一名C风格的开发人员被VB34戴上手铐,我无法在VB.NET中找到所提供示例的语法等效,尽管我已经到目前为止.

我相信NHibernate是最好的选择,但作为一名软件顾问,我不能(不想)错过重要的技术变革,改进和发展.

尽管我读到了关于EF1的不好评论,但EF4看起来非常有前景.您对NHibernate和Entity Framework途径的看法是什么？至于我,我对所有的阅读都感到困惑.我需要你把头伸出水面.

谢谢大家!

Answer 1

我对EF几乎一无所知,但快速浏览所提供的链接让我相信EF与Fluent NHibernate的Automapping功能无关.

编辑:一些评论者向我指出了指示EF中有一些自动化的链接,但它不是很清楚它是否像FNH一样强大(例如,能够自动化其他对象的集合).

就个人而言,我喜欢能够以OO方式设计POCO,并让该工具处理映射到关系数据库的所有繁忙工作.

据我所知,FNH仍具有最强大的自动化功能.

有关更多信息,请访问Fluent NHibernate Automapping.

Answer 2

对此持保留态度。我不是 ORM 工具方面的任何权威，但事情是这样的......

我在 EF 中看到的最大好处之一是用于映射的 GUI。IMO，这节省了大量时间，但这可能就是 EF XML 映射如此冗长的原因。不幸的是，它们并不是为了手动处理而设计的。会不会改变我不知道。我所知道的是，EF 提供的 GUI 在以前的版本中曾经非常不稳定。我仍然听到有人抱怨它的扩展性不好，特别是在更大、更复杂的模式上，它会错过一些东西，最终会直接弄乱映射。我的观点是，随着 EF 的成熟，XML 映射将变得不再那么冗长。您还可以在 EF 中获得流畅的映射支持，这也很有帮助。最后，另一件大事是能够更改 EF 生成的代码模板，也就是说，如果您喜欢数据库驱动的设计而不是设计优先的方法。

另一个好处是它来自微软，他们有足够的资金使其成为一个真正出色的框架。在过去的几年里它有了巨大的增长。我认为它会在一年多一点的时间里与 NHibernate 处于同样的地位。到目前为止，我认为 NHibernate 是一个更好的选择。它更加稳定和成熟。配置相对容易，最重要的是性能更好。我认为如果你设计得当，从一个到另一个的迁移将是小菜一碟。

EF只是一个抽象。我相信有 Oracle 的提供商，所以我不明白为什么随着它的发展不能添加更多提供商。