MS Entity Framework VS NHibernate 及其派生贡献（FluentNHibernate，Linq for NHibernate）答案

【问题标题】：MS Entity Framework VS NHibernate and its derived contribs (FluentNHibernate, Linq for NHibernate)MS Entity Framework VS NHibernate 及其派生贡献（FluentNHibernate，Linq for NHibernate）
【发布时间】：2010-02-04 16:35:43
【问题描述】：

我刚刚阅读了关于 Entity Framework 4（实际上是版本 2）的 article。

Entity Framework 似乎比其第一个版本提供了巨大的改进。因此，我从未在任何项目中使用过 EF，因为我认为 EF 与 NHibernate 相比还不够成熟。

NHibernate 及其当前贡献的FluentNHibernate 和Linq for NHibernate by Ayende Rahien

我的感觉是，当 NHibernate 的第二版问世时，Microsoft 只是想获得它已经失去的支持 NHibernate 的领域。尽管如此，我的担忧是以下（不按特定顺序）：

EF4 的 XML 冗长性会降低吗？
EF4 是否与 SQL Server 以外的基础数据存储兼容？
使用 EF4 而不是 FluentNHibernate 或 NHibernate 本身的最大好处是什么？

NHibernate 是一个很棒的工具，我想每个人都同意。由于它的前身 Hibernate，我们可以很容易地找到文档和教程以及示例应用程序来熟悉它。 FluentNHibernate 并非如此。特别是根据我现在正在进行的项目，这要求我进一步调查 NHibernate 及其选项（例如 FluentNHibernate），以便记录 NHibernate 和 FluentNHibernate 技术的使用规则和最佳实践。因此，被 VB.NET 束缚，作为 C 风格的开发人员，我无法在 VB.NET 中为所提供的示例找到一些语法等价物，尽管到目前为止我已经做到了。

我确实相信 NHibernate 是最佳选择，但作为一名软件顾问，我不能（不想）错过重要的技术变革、改进和演进。

尽管我读到的关于 EF1 的 cmets 很糟糕，但 EF4 似乎很有希望。你们都对 NHibernate 和实体框架途径有什么看法？至于我，我对所有这些读数感到困惑。我需要你把我的头从水里捞出来。

谢谢大家！

【问题讨论】：

根据回答的点赞数，我接受了点赞最多的回答。此外，你们都有很好的方法和答案，并启发了我对这两种技术的未来研究做出正确的决定。我要感谢你们所有人，很抱歉不能接受你们所有的回答作为我问题的“解决方案”。谢谢！

标签： c# vb.net nhibernate entity-framework fluent-nhibernate

【解决方案1】：

我对 EF 几乎一无所知，但快速浏览所提供的链接让我相信 EF 不具备 Fluent NHibernate 的自动映射功能。

编辑： 一些评论者向我指出 EF 中有一些自动映射的链接，但不清楚它是否与 FNH 一样强大（例如，能够自动映射其他对象的集合）。

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

据我所知，FNH 仍然拥有最强大的自动映射功能。

转至Fluent NHibernate Automapping 了解更多信息。

【讨论】：

感谢您的回答！因此，我将发现 Fluent NHibernate 提供的强大功能，因此我还没有探索 Automapping 功能。我读了几行关于它的文章，但我首先需要让 FNH 工作，这样我才能理解 Automapping 为用户做了什么。那是个很好的观点！你让我想到在更深层次上探索 FNH。或许值得成为拥有这种技术的某种专家。谢谢！
实际上，EF 提供了一个与 Fluent NHibernate 非常相似的配置生成器实用程序。这是一篇谈论它的文章：blogs.msdn.com/adonet/pages/…
@user68137：谢谢！对于这个链接。我不会错过访问此链接的机会。
@user68137：我查看了链接 - 非常有趣。我不清楚的一件事 - 模型中的每个业务对象都需要 EF 配置类吗？如果是，那么这与 FNH Automapping 不同（但它等同于 FNH 中所谓的“Fluent Mapping”，您需要为每个业务对象添加一个额外的 Mapping 类）。 FNH Automapping 不需要额外的 Mapping 类——它严格从业务类构建数据库，将程序员的工作量减少了大约一半。请澄清，我会相应地编辑我的答案。
@Will：如果答案有用，那么点个赞就好了...:-)。对我来说，Automapping 的学习曲线相当陡峭，因为这是我第一次接触 FNH，而且文档有限。但现在我有了一些经验，它提供了巨大的生产力提升。我可以（几乎）随意创建和更改对象模型，并让 FNH 为我重建数据库。值得一看，海事组织。我添加了指向我的答案的链接。

【解决方案2】：

EF4 的 XML 冗长性会降低吗？

一般来说，我没有看到任何迹象表明 XML 会大不相同。 Microsoft 在 v4 中为 EF 提供了类似 Fluent 的接口，但它是一个附加/单独下载。

EF4 是否与 SQL Server 以外的其他底层数据存储兼容？

它现在是兼容的，并且它将在未来保持兼容。 LinqToSql 只是 SQL Server，但 EF 从来都不是 SQL Server。

使用 EF4 而不是 FluentNHibernate 或 NHibernate 本身的最大好处是什么？

老实说，数量并不多。这里和那里有一些不同的地方，但总的来说 NHibernate 仍然领先 EntityFramework 数年，即使在 EFv4 中也是如此。

作为一名顾问，您可能值得花时间成为 NHibernate 和实体框架方面的专家。您可能会继续在现实世界中看到它们。微软在数据访问方面的注意力往往很短，因此不清楚 Entity Framework 几年后的位置。因为它来自 Microsoft，所以可以肯定很多开发人员会使用 EF。

【讨论】：

我有 EF 只是 SQL Server 的标题。应该是谣言吧！ =) 我对 ORM 的 LinqToSql 实现做了一点工作，我并不讨厌。虽然它毕竟是一个好方法，但你提到了它，它只是 SQL Server。因此，我无法真正使用它。作为大多数框架类型的开发人员，我需要精通我的代码才能快速做出反应。无论如何，我想你说 EF 和 NH 将在不久的将来共存是对的。非常感谢您的观点！你真的帮助启发了我对这个主题的想法。

【解决方案3】：

把这个和一粒盐一起吃。我不是 ORM 工具的任何权威，但它就在这里......

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

另一个好处是它来自微软，他们有足够的资金使这个框架成为一个真正的涂料框架。在过去的几年里，它发展得非常快。我认为它会在一年多一点的时间内与 NHibernate 保持一致。到目前为止，我认为 NHibernate 是一个更好的选择。它更加稳定和成熟。相对容易配置，最重要的是性能更好。我认为，如果您设计明智，从一个转移到另一个将是小菜一碟。

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

【讨论】：

NHibernate 有 GUI/视觉设计师。
EF4 允许设计优先的方法。它允许您插入自己的域模型并使用 XML 映射或类似于 Fluent Nhibernate 的基于代码的流畅方法将其映射到您的数据结构。另一种选择是利用现有结构并基于它创建领域模型。这是数据库驱动的方法。 EF4 允许您调整它用于域生成的模板，这可以成功消除 EF 吐出的一些膨胀。
如果您决定开始对数据进行版本控制以让 EF 处理并发操作，那么您需要更改现有表的唯一方法是。我的意思是，这是处理该问题的选项之一。您也可以以编程方式执行此操作，而无需任何数据库更改。否则，您可以重复使用现有结构。
@Micheal Maddox：这些用于 NHibernate 的 GUI/视觉设计师是什么？我什么都不知道。
迈克尔实际上可能是对的。我认为 Sculpture 有一个适用于 NHibernate 的模型。从未使用过，但它看起来是一个很酷的解决方案。