实体框架4与NHibernate

Question

很多人都在网上讨论过Entity Framework的第一个版本（也就是stackoverflow），很明显，当我们已经拥有像NHibernate这样的更好的选择时，它不是一个好的选择。但我找不到实体框架4和NHibernate的良好比较。我们可以说今天NHibernate是所有.NET ORM中的领导者，但是我们可以期待Entity Framework 4从这个位置取代NHibernate。我认为如果微软真的在EF4中注入了非常好的功能，它可以给NHibernate带来很好的竞争，因为它具有Visual Studio集成，更易于使用，并且在大多数商店中总是优先考虑MS产品。

Answer 1

EF4在“自我跟踪实体”中对n层开发有一个开箱即用的答案。没人发布NHib的可比代码。

NHib有很多未被提及作为EF4一部分的功能。这些包括二级缓存集成。它还具有更大的继承映射灵活性，与存储过程/数据库函数/自定义SQL /触发器的更好集成，对公式属性的支持等。 IMO它基本上只是作为ORM更加成熟。

Answer 2

更新：自版本4.0以来我没有使用过Entity Framework，所以我的回答可能已经过时了。我仍然在我的项目中使用NH或纯ADO .NET。而且我甚至不想看看自4.0以来EF中的新功能，因为NH工作得很好。

当你使用两者时，实际上很容易比较它们。 EF4有一些严重的限制，我可以说出我自己遇到的一些问题：

EF4问题：

• 渴望加载和整形结果：EF4 eager加载系统（包含（“路径”））生成不正确的SQL，循环JOIN，对于许多人来说，执行数千次（非字面）时间更慢 - to-many relationship然后手写SQL（它实际上无法使用）。
• Materializer无法实现关联实体：如果您认为通过提供自己的SQL查询可以克服以前的问题，那么您就错了。 EF4无法从JOIN SQL查询中实现（映射）关联实体，它只能从一个表加载数据（所以如果你有Order.Product，SELECT * FROM命令LEFT JOIN产品将只初始化Order对象，Product将保持为null，认为在查询中获取所有必要的数据以初始化它）。这可以通过使用EFExtensions社区附加组件来克服，但是您必须为此编写的代码非常难看（我尝试过）。

• 自我跟踪实体：很多人说自我跟踪实体对于N层开发来说很酷，包括此主题中的最佳答案。以为我甚至都没试过，我可以说它们不是。每个输入都可以伪造，你不能简单地接受用户发送给你的更改并将它们应用到数据库，为什么不给用户直接数据基地访问呢？你将不得不加载数据用户的任何方式即将从DB更改，检查它是否存在，不存在权限检查等等。你不能信任用户对他发送到服务器的实体的状态，无论如何必须从数据库加载这个实体并确定它的状态和其他东西，所以这些信息是无用的，自我跟踪实体也是如此，除非你做一个私人信任的n层系统供内部使用，在这种情况下你可以给出简单的数据库访问。 （多数民众赞成我关于ST实体和N轮胎的想法，我在N-Tier中没有经历过，所以它可以改变，如果我误解了这里的内容，请注释）

• 记录，事件，整合业务逻辑：EF4就像黑盒子一样，它做了一些事情，你不知道它做了什么。只有一个事件OnSavingChanges，你可以在DB发生某些事情之前放置一些你需要运行的业务逻辑，如果你需要在事情发生之前对业务对象应用一些更改，你将不得不深入挖掘ObjectStateManager，这真的很难看，代码可以变得巨大。例如，如果您使用Repository模式以及以干净对象方式对DB所做的更改通知的内容，那么您将很难使用EF进行此操作。

• 可扩展性：所有EF代码都是私有和内部的，如果你不喜欢的话（如果你认真对待EF使用你就不会喜欢），不管你怎么做将以简单的方式改变这一点，事实上，我确信从头开始编写自己的ORM（我做的）然后根据需要使EF工作更容易。作为示例，看一下EFExtensions源代码，它基于扩展方法，以及不同的“黑客”使EF更加可用，代码非常难看（并且这不是作者的错，当EF中的所有内容都是私有的时候这是唯一的扩展它的方法）。

我可以继续写关于EF的不好的事情，以及让我用20页来处理它的痛苦，也许我会。

NHibernate怎么样？这是完全不同的水平，就像比较PHP和C＃，EF4就像Stone-age一样，就像EF在发展进程中落后于NHibernate 10年，事实上是的，Hibernate是在2001年开始的。如果你有空闲时间学习并打开Nhibernate，那就去做吧。

Answer 3

这就是事情。在我看来，NHibernate和Entity Framework真的适合两个不同的受众。 NHibernate将是我构建具有复杂映射，公式和约束（基本上是任何企业）的系统的选择。如果我想通过简单的数据访问实现运行，我会使用Entity Framework或LINQ-to-SQL。 NHibernate没有像EF那样清晰的“拖放”体验。两者都有其优点和缺点。坦率地说，比较他们苹果对苹果，无处可去。

Answer 4

如果您认为自己可能想在Mono上运行代码，那么NHibernate可能是更好的选择，无论功能清单如何...

编辑，2012年8月13日：

实体框架一直是开源的，现在从2.11.3开始包含在Mono中。这个答案现在已经过时，不应该依赖。

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx

Answer 5

我对此的看法是EF4.0从1.0开始已经走了很长一段路，并且在功能上赶上了Nhibernate，但它还不是全部。

然而，它是开箱即用的微软，并完成95％的应用程序需要它做的100％。然而，NHibernate多年来一直在做同样的事情。 5.0或6.0版可能会赶上，甚至超过NHibernate。

这是我的建议 - 如果你有时间学习两者，那就去做吧。选择一个而不是另一个有几个原因。如果您正在为公司编写代码，那么期望能够熟悉EF的员工是可行的，就像在所有书籍中以及孩子在大学里学到的东西一样。如果EF能够满足你的要求（在说“是”之前想想这个很长很难），那么现在它是一个非常好的解决方案，并且在几年内它可能（好吧，很可能会）超过NHibernate。

NHibernate是一款非常成熟的产品，在EF上用了几年时间，很可能会做你想做的一切，然后做一些。它现在已成为最好的ORM，并且很多人都在使用它。

Answer 6

我认为EF 4能够使用POCO和延迟延迟加载的事实将非常大。我肯定能看到它在新版本中获得牵引力。

Answer 7

与NHibernate相比，EF普及率明显增加trend，见图。

Answer 8

我的2美分：我们在桌面客户端上使用ef来获得一些cahing等 - 没有高负荷。 服务器端的NHib - 利用无状态会话，hilo id生成和批处理。 以每秒db的速度插入3k +消息是非常快的。它也非常灵活，支持大量的dbs，这对我们的产品至关重要。

Answer 9

使用Linq组合逻辑层直接映射到存储过程似乎是最简单的方法。没有xml。仅为不常使用或不适合存储过程的有趣查询生成sql。

对象通过标准SP加载和存储。这种方法允许使用两个sql登录。一个用于通过SP访问类（仅执行权限），另一个用于允许直接表访问的逻辑linq模块。

Answer 10

按照受欢迎程度选择ORM并不是最好的选择。 在过去的两年里，我试图转向EF，我只能说，为什么我还在尝试？

ATM我对EF的看法是：“它是为非常小的非常小的系统而制作的，不超过3个表，关系少于1（0更好）”。

为什么我这么想？ 1.尝试更新断开连接的图表并查看模型划痕;

1. 尝试使用深度继承树制作TPH，您会发现自己被绑定到单个层次结构或系统将中断。

2. 尝试进行更繁琐的查询，并观察整个系统是否已经耗尽堆栈：D ...经常发生溢出。

3. Map XML数据类型基于扩展或最“讨厌”的NotMapped属性......而且情况更糟。

4. 尝试将SQL查询混合到Linq以获取更多finner查询，然后您将破坏墙壁lol。

5. 最后也是最重要的一点是，EF不支持属性公式（'NH为遗留数据库提供了一个很棒的资源'），并且不支持同一个表和相关表的复杂类型映射。 / p>

那是我的10cc。