.net 实体框架 4 与 NHibernate

Entity Framework 4 vs NHibernate

提问by Deependra Solanky

A lot has been talked about Entity Framework first version on the web (also on stackoverflow) and it is clear that it was not a good choice when we already have better alternative like NHibernate. But I can't find a good comparison of Entity Framework 4 and NHibernate. We can say that today NHibernate is the leader among all .NET ORMs, but can we expect Entity Framework 4 to displace NHibernate from this position. I think if Microsoft has really injected very good features in EF4 it can give good competition to NHibernate as it has Visual Studio integration, easier to work with and preference is always given to MS products in most shops.

在网络上（也在 stackoverflow 上）已经讨论了很多关于 Entity Framework 的第一个版本，很明显，当我们已经有了像 NHibernate 这样更好的替代方案时，它显然不是一个好的选择。但是我找不到 Entity Framework 4 和 NHibernate 的一个很好的比较。我们可以说今天 NHibernate 是所有 .NET ORM 中的佼佼者，但我们能不能指望 Entity Framework 4 取代 NHibernate 从这个位置。我认为如果微软真的在 EF4 中注入了非常好的功能，它可以与 NHibernate 进行良好的竞争，因为它具有 Visual Studio 集成，更容易使用并且大多数商店总是优先考虑 MS 产品。

采纳答案by John Rayner

EF4 has an out-the-box answer with regard to n-tier development, in "self-tracking entities". Nobody has released comparable code for NHib.

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

NHib has many features that have not been mentioned as being part of EF4. These include the second-level cache integration. It also has greater flexibility in inheritance mapping, better integration with stored procs / database functions / custom SQL / triggers, support for formula properties and so on. IMO it's basically just more mature as an ORM.

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

回答by Alex Burtsev

Update:I haven't used Entity Framework since version 4.0, so my answer can be outdated. I'm still using NH or pure ADO .NET in my projects. And I don't even want to look at what's new in EF since 4.0, because NH works perfectly.

更新：我从 4.0 版开始就没有使用过实体框架，所以我的答案可能已经过时了。我仍然在我的项目中使用 NH 或纯 ADO .NET。而且我什至不想看 EF 自 4.0 以来的新内容，因为 NH 完美运行。

Actually is pretty easy to compare them when you have used both. There are some serious limitations with EF4, I can name some which I encountered by my self:

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

EF4 problems:

EF4 问题：

• Eager Loading and shaping the result: EF4 eager loading system (Include("Path")) generates improper SQL, with looping JOIN's , which will execute thousands(not literally) time slower for many-to-many relationships then hand written SQL (it's effectively unusable).
• Materializer can't materialize associated entities: If you can think you can overcome previous problem by providing you own SQL query, you are wrong. EF4 can't materialize(map) associated entities from JOIN SQL query, it can only load data from one table (So if you have Order.Product, SELECT * FROM order LEFT JOIN Product will initialize only Order object, Product will remain null, thought all necessary data is fetched in query to init it ). This can be overcome by using EFExtensions community add-on, but the code you will have to write for this is really ugly (I tried).

• Self-Tracking Entities: Many say that Self-tracking entities are cool for N-tier development including the top answer in this thread. Thought I haven't even give them a try, I can say they are not.Every input can be forged, you can't simply take the changes that user sends you and apply them to data base, why not give the user direct data base access then? Any way you will have to load the data user is about to change from DB, check that it exist|not exists do permissions checks etc etc. You can't trust user on the state of entity he is sending to server, you will anyway have to load this entity from DB and determine it's state and other things, so this information is useless, as do Self-Tracking entities unless you do a private trusted n-tier system for internal use, in which case maybe you could give just plain DB access. (Thats my thoughts about ST Entities and N-tire, I'm not very expericned in N-Tier, so it can change, if I misunderstood something here comment it)

• Logging, Events, integrating business logic:EF4 is like black box, it do something and you have no idea what it do. There is only one event OnSavingChanges where you can put some business logic you need to run before something happens with DB, and if you need to apply some changes to business objects before something happens you will have to dig in ObjectStateManager, and this is really ugly, code can become huge. If you for example using Repository pattern and what to be notified on changes made to DB in clean object way, you will have hard time doing this with EF.

• Extensibility:All EF code is private and internal, if you don't like something (and you will not like a LOT if you are serious about EF using), no way you will change this in easy way, In fact I'm sure it's easer to write you own ORM from scratch (I did) then make EF work as you need. As example take a look at EFExtensions source, it's based on extensions methods, and different "hacks" to make EF little more usable, and the code is pretty ugly (and it's not authors fault, when everything in EF is private this is the only way to extend it).

• 急切加载和塑造结果：EF4 急切加载系统 (Include("Path")) 生成不正确的 SQL，带有循环 JOIN's ，对于多对多关系，它将执行数千（不是字面意思）时间慢于手写 SQL（它是实际上无法使用）。
• Materializer 无法实现关联实体：如果您认为可以通过提供自己的 SQL 查询来克服以前的问题，那您就错了。EF4 无法从 JOIN SQL 查询中具体化（映射）关联实体，它只能从一个表中加载数据（因此，如果您有 Order.Product，SELECT * FROM order LEFT JOIN Product 将仅初始化 Order 对象，Product 将保持为 null，认为所有必要的数据都在查询中获取以初始化它）。这可以通过使用 EFExtensions 社区附加组件来克服，但是您必须为此编写的代码非常丑陋（我尝试过）。

• 自我追踪实体：许多人说自跟踪实体对于 N 层开发很酷，包括这个线程中的最佳答案。以为我什至没有尝试过，我可以说他们没有。每个输入都可以伪造，您不能简单地将用户发送给您的更改应用到数据库中，为什么不给用户直接数据基地访问呢？您必须以任何方式加载用户即将从数据库更改的数据，检查它是否存在|不存在权限检查等。您不能信任用户发送到服务器的实体状态，无论如何您都会必须从数据库加载这个实体并确定它的状态和其他东西，所以这些信息是无用的，自我跟踪实体也是如此，除非你做一个私人可信的 n 层系统供内部使用，在这种情况下，你可以简单地给出数据库访问。

• 日志记录、事件、集成业务逻辑：EF4 就像黑匣子，它做了一些事情，你不知道它在做什么。只有一个事件 OnSavingChanges，您可以在其中放置一些您需要在 DB 发生某些事情之前运行的业务逻辑，并且如果您需要在某些事情发生之前对业务对象应用一些更改，您将不得不在 ObjectStateManager 中进行挖掘，这真的很难看，代码可以变得巨大。例如，如果您使用存储库模式以及以干净的对象方式对数据库所做的更改通知什么，则您将很难使用 EF 执行此操作。

• 可扩展性：所有 EF 代码都是私有的和内部的，如果你不喜欢某些东西（如果你认真对待 EF 的使用，你不会喜欢很多），你不可能以简单的方式改变它，事实上我敢肯定从头开始编写自己的 ORM（我做到了），然后根据需要让 EF 工作更容易。例如，看看 EFExtensions 源代码，它基于扩展方法和不同的“技巧”，使 EF 更有用，并且代码非常丑陋（这不是作者的错，当 EF 中的所有内容都是私有的时，这是唯一的方法来扩展它）。

I can continue to write bad things about EF and how painful it was for me to work with it for like 20 pages, and maybe I will.

我可以继续写关于 EF 的坏事，以及用它工作大约 20 页对我来说是多么痛苦，也许我会。

What about NHibernate?It's absolutely different level, it's like comparing PHP to C#, EF4 is like in Stone-age, it's like EF is 10 years behind then NHibernate in development progress, and in fact it is, Hibernate was started in 2001. If you have free time to learn and switch on Nhibernate, do it.

NHibernate 呢？完全不同的层次，就像PHP和C#比较，EF4就像石器时代，EF比NHibernate的开发进度落后10年，实际上是，Hibernate是2001年开始的。如果你有空的话要学习和开启 Nhibernate，就去做吧。

回答by zowens

Here's the thing. NHibernate and Entity Framework are really for two different audiences, in my mind. NHibernate would be my choice in building a system with complex mappings, formulas, and constraints (basically anything enterprise). If I wanted to hit-the-ground running with simple data access, I would use Entity Framework or LINQ-to-SQL. NHibernate doesn't have a clear "drag-and-drop" experience quite like EF. Both have their strengths and drawbacks. Comparing them apples-to-apples, frankly, gets you nowhere.

这是事情。在我看来，NHibernate 和实体框架确实适用于两种不同的受众。NHibernate 将是我构建具有复杂映射、公式和约束（基本上任何企业）的系统的选择。如果我想通过简单的数据访问立即运行，我会使用实体框架或 LINQ-to-SQL。NHibernate 没有像 EF 那样清晰的“拖放”体验。两者都有其优点和缺点。坦率地说，将它们逐个进行比较，您一无所获。

回答by Joel Mueller

If you think you might ever want to run your code on Mono, NHibernate is probably a better choice no matter what the feature checklists say...

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

Edit, 8/13/2012:

2012 年 8 月 13 日编辑：

Entity Framework has been open-sourced, and is now included in Mono as of 2.11.3. This answer is now outdated and should not be relied upon.

Entity Framework 已经开源，现在从 2.11.3 开始包含在 Mono 中。这个答案现在已经过时，不应依赖。

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

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

回答by Dean

My take on this is that EF4.0 has came a long way since 1.0 and is catching up to Nhibernate in functionality, but it's not all there yet.

我对此的看法是，EF4.0 自 1.0 以来已经取得了长足的进步，并且在功能上正在追赶 Nhibernate，但还不是全部。

However it is Microsoft, out of the box, and do 100% of what 95% of applications need it to do. However, NHibernate has been doing the same thing for years. Come version 5.0 or 6.0 may catch up, or even surpass NHibernate.

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

Here is my advice -- if you have time to learn both, then do it. There are several reasons to choose one over the other. If you are writing code for a corporation, it is realistic to expect to be able employees who would be familiar with EF, as it's in all the books and what kids learn in college. If EF will meet your requirements (think about this one long and hard before just saying yes), then it's a perfectly fine solution for now, and in a few years it may (ok, most likely will) surpass NHibernate.

这是我的建议——如果你有时间学习两者，那就去做吧。选择一个而不是另一个的原因有很多。如果您正在为公司编写代码，那么期望成为熟悉 EF 的有能力的员工是现实的，因为它在所有书籍中以及孩子们在大学学到的内容中都有。如果 EF 能够满足您的要求（在说“是”之前仔细考虑这个问题），那么它现在是一个完美的解决方案，几年后它可能（好吧，很可能会）超过 NHibernate。

NHibernate is a very mature product with a few years on EF and will most likely do everything you would ever want to do and then some. It has been the best ORM for a while now and a lot of people use it.

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

回答by YeahStu

I think the fact that EF 4 will have the ability to use POCO and deferred lazy loading will be very big. I could definitely see it gaining traction with the new release.

我认为 EF 4 将具有使用 POCO 和延迟延迟加载的能力的事实将非常大。我绝对可以看到它随着新版本的发布而获得吸引力。

回答by Tomas Kubes

There is an obvious trendof increasing EF popularity over NHibernate, see the picture.

EF 流行度比 NHibernate有明显增加的趋势，见图。

回答by Aleksei Anufriev

My 2 cents: we use ef on our desktop client for some cahing etc - no hi loads. An NHib on server side - utilizing Stateless sessions, hilo id generation and batches. Is is quite fast in inserting 3k+messages in db per second. Also it is very flexible and supports lots of dbs, wich is crucial for our product.

我的 2 美分：我们在桌面客户端上使用 ef 进行一些缓存等 - 没有高负载。服务器端的 NHib - 利用无状态会话、hilo id 生成和批处理。Is在每秒以db中插入3k+条消息的速度非常快。此外，它非常灵活并支持大量数据库，这对我们的产品至关重要。

回答by Andrew

Mapping directly to stored procedures with a combination of Linq for a logical layer seems the easiest approach. No xml. Generate sql only for interesting queries that are less frequently used or not suitable for stored procedures.

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

Objects load and store through standard SPs. This approach allows the use of two sql logins. One for the class access through SPs (execute-only permissions) and one for a logical linq module that allows direct table access.

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

回答by Moisés Gon?alves

Choosing between ORM's by popularity isn't the best thing to do. I've tried to move to EF the past 2years and all I can say is, why the hell I still try to?

根据流行程度在 ORM 之间进行选择并不是最好的选择。在过去的 2 年里，我一直试图转到 EF，但我只能说，我到底为什么还要尝试？

ATM my point of view about EF is: "It's made for really small pretty tiny bit systems with no more than 3 tables with less than 1 relationship (0 is better)".

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

And why do I think like that? 1. Try to update a disconnected graph and see your model scratch;

为什么我会这样想？1.尝试更新一个断开连接的图形，看看你的模型划痕；

1. Try to make TPH with deep inherited trees and you'll find you that you are schackled to a single hierarchy or the system will break.

2. Try to make more cumbersome queries and watch the whole system eat out the stack :D... overflows happen very often.

3. Map XML datatypes is based on extensions or the most "hated" NotMapped properties... and it's even worse.

4. Try mixing SQL query into Linq for more finner queries and you'll break the wall lol.

5. And the last and most important thing, EF doesn't support property formula ('an awesome resources NH has for legacy databases'), and doesn't support complex type mappings for same table and related tables.

1. 尝试使用深层继承树来制作 TPH，你会发现你被束缚在一个单一的层次结构中，否则系统就会崩溃。

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

3. Map XML 数据类型基于扩展或最“讨厌”的 NotMapped 属性……甚至更糟。

4. 尝试将 SQL 查询混合到 Linq 中以获得更精细的查询，你会打破壁垒，哈哈。

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

That's my 10cc.

那是我的10cc。