ADO.NET 实体框架与 NHibernate [关闭]

Posted 2023-02-16

【中文标题】ADO.NET 实体框架与 NHibernate [关闭]

【英文标题】：ADO.NET Entity Framework vs NHibernate [closed]

【发布时间】：2010-09-06 07:08:01

【问题描述】：

因此，ADO.NET 实体框架受到了一些负面报道（以博客条目和请愿书的形式），但我不想急于做出判断。我的实验时间有限，但我想知道是否有人使用它并获得更多经验反馈？

最后，关于使用已经存在很长时间并且可能比 ADO.NET Entity Framework 更成熟的 NHibernate 有什么想法。

【参考方案1】：

如果零配置是 SubSonic 的主要优势，您可以查看 Fluent nHibernate 或实体框架代码优先

来自 Răzvan Panda 的更新：由于 NHibernate 本身包含代码映射，Fluent NHibernate 已基本过时，请参阅：notherdev.blogspot.ie/2012/02/

【讨论】：

Entity Framework Code First 也是零配置，实际上你甚至不需要连接字符串来运行它。

@Lavinski Yeh，现在有。但在 2009 年 8 月 19 日，当我留下此评论时，没有。

更有理由让它保持最新状态。

Fluent NHibernate 已被 NHibernate 本身包含在代码映射中，大部分已过时，请参阅：notherdev.blogspot.ie/2012/02/…

【参考方案2】：

距离原帖已经过去 2 年了。据我了解，ADO.NET Entity Framework 在 .net 4 中已经成熟。有人对此主题有任何新的反馈吗？

这是自 2008 年首次发布以来添加到 EF 的改进的链接 http://blogs.msdn.com/b/adonet/archive/2009/05/11/update-on-the-entity-framework-in-net-4-and-visual-studio-2010.aspx

更新：我在堆栈溢出中发现了这个线程，它很好地讨论了更新的 EF：

Entity Framework 4 vs NHibernate

【参考方案3】：

我开始喜欢 Entity。弄清楚它的所有错误消息的含义需要一段时间，但是一旦你习惯了它，它确实做得很好。它目前最大的缺点是不支持断开连接。

【参考方案4】：

我使用过 SubSonic、LinqToSql、LinqToEntities。现在我正在尝试 NHibernate。现在 - 我喜欢 NHibernate（可能是因为我遇到的问题还不够多）。最糟糕的是——LinqToEntities（当然，这只是我的看法）。

【参考方案5】：

我确实对 SubSonic 有疑问。 SubSonic 在名称相同但架构不同的表上窒息而死。我不想讨论构建数据库的最佳实践，因为我并没有要求这样做。（当谈到提出意见并保住工作时，我宁愿保住工作。： ))

【讨论】：

这是一个很好的见解 - 我工作时有人以相同的方式设计了一个数据库，其中跨多个模式的重复名称。

【参考方案6】：

NHibernate 可能更成熟。这并不一定意味着它是一个“更好”的解决方案。在我的工作中使用它一段时间后，我个人更喜欢使用 NHibernate 之外的任何东西（即使是直接 SQL，如果迁移是远程可行的）。 NHibernate 抛出的没有任何意义的错误消息的数量（或确实意味着某事但不应该发生）绝对是惊人的，它的一些默认行为也是如此（例如为 Find 中返回的每个对象刷新一次会话)。

就个人而言，当我有选择时，我会使用 LINQ to SQL 来处理所有数据库工作。

【讨论】：

最近在“领域”中出现的下降支持是否让您质疑这个决定？我觉得好像我需要放弃它，因为担心未来的支持需求会被女士忽略。想法？

我并不十分担心。如果它被完全放弃（不太可能），第三方总是有可能在普通 LINQ 之上构建一个 LINQ to SQL 层（这不会去任何地方），类似于执行 LINQ to AD 或 LINQ to NHibernate 的组。几乎肯定有人会这样做。

我最喜欢的是“预期受影响的行数：1，实际受影响的行数：0”，没有解释，甚至没有表名。还有更多，但那是相当具有示范性的。

@Brady Gaster LINQ 和 EF 无处可去。 MS 正在大力推动 EF，并真正听取了社区的意见。我同意他们还有很多需要改进的地方，但我毫不怀疑他们会。

【参考方案7】：

微软几乎承认 ADO.Net 实体框架不是 ORM（我目前找不到参考资料）。因此，如果您将实体框架视为一个查询引擎，那么显然它确实擅长它的功能。但是，对于完整的 ORM 解决方案，您可能希望在别处寻找。

以下博客文章似乎证实了这种差异：

http://blogs.msdn.com/dsimmons/archive/2008/05/17/why-use-the-entity-framework.aspx