实体框架与NHibernate - 性能

Question

我希望在我们的系统中实现ORM。我们目前有很多表，有很多可怕的数据和存储过程。我听说使用ORM会降低系统速度。有没有人知道哪个ORM使用在C＃代码中创建的查询和映射到存储过程的速度和性能更好？

由于

编辑：

项目将使用大型且包含大量数据的现有表，它还将使用在SQL Server DB中执行复杂任务的现有存储过程。在运行现有存储过程和查询当前表时，ORM必须能够执行事务并具有高性能。该项目是基于Web的，将使用带有DDD的WCF Web服务。我可以看到EF更容易使用并且有更大的支持，但如果NH是最合适的选择吗？

Answer 1

实体框架不断实施新功能，一切都在您的项目中实现自动化。使用Entity Framework非常容易，扩展和重构代码。 Visual Studio将它集成在一起（Code-First，Database-first，Entity-First ......）就像魅力一样。 Windows Azure易于部署和更改。 此外，Visual Studio可以通过3次点击生成所有CRUD页面。

我建议您使用EF，但这取决于您的项目。你能告诉我们更多关于它的细节吗？

您可以在Google上找到许多比较图表，例如this one解释性能和this one差异。

编辑：

您能否量化应用程序中的用户数量？

当您在EntityFramework中使用Database-First时，import and use stored procedures非常容易，对于NHibernate也是quite simple。 请注意，如果您使用大量存储过程而不是大量并发用户，那么在这两者之间选择ORM可能并不那么重要。

另外不要忘记工具的性能通常是基于使用它的方式。如果你滥用ORM（例如异步，懒惰/急切加载，基类......），性能将大幅下降。

也许你可以安装它们，看看它们是如何工作的，并检查它们的路线图（例如Entity framework）以检查它们的演变和兴趣。

Answer 2

两者都是很好的解决方案，尽管我个人认为NHibernate对于继承的数据库更好。这是一个很好的功能比较 -

http://www.dennisdoomen.net/2013/03/entity-framework-56-vs-nhibernate-3.html

在NHibernate中有一些明显更好的东西，比如二级缓存支持。文档可能比EF更稀疏，但如果你愿意经历学习曲线，NHibernate会给你更多的力量。

FluentNHibernate非常适合类到基础表的类型映射，但有些地方你只需要恢复为XML映射。然而，有一个新的竞争API来自NHibernate本身，我还没有检查过它（上面的博客文章提到它）。

如果您想依赖VS工具支持，EF会更好。然而，有时候会有一些魔法（例如，EF可以使用反射甚至填充对象的私有属性，NHibernate不这样做;这是一种力量或弱点，取决于你如何看待它）。 EF也适用于其他Microsoft提供的框架（例如RIA服务）。我也喜欢EF-auto迁移（当你使用代码优先时）。

如果你想要掌握更多权力，并希望能够通过明确的关注点分离（ORM只做ORM应该做的事情）微调事情的方式，那么NH似乎更好。然而，让NH的所有属性都能够访问它们有点令人恼火。

我已经使用了两者，有时可能会有点笨拙地生成你想要的sql;在那些5-10％的情况下，再下降一个级别并使用像Dapper，Massive或Petapoco这样的微观。

编辑：

NHibernate也可以填充私人财产，看起来，所以这只是我的无知。

Answer 3

.NET 4.5上的EF 5或6 是提高性能的一种可靠方法，不要指望在.NET 4.0上使用EF 5可以提高速度，这是Microsoft记录的。 （我们还有另一个问题，那就是写得不好的LINQ语句）。

通常，如果性能是高优先级，则无法使用存储过程击败ADO.NET。你根本做不到。添加了ORM，添加和IOC容器...您想要做多少性能测试？

使用JMETER启动一些虚拟机并使用EF命中服务器并使用NHibernate命中另一个虚拟机，您只需强制JMETER对URL进行足够的调用并测试并发用户数量，您应该看到您的瓶颈所在。

Answer 4

check this artical NH超过EF的一些优点

1. NH有10多个id生成器策略（IDENTITY，序列，HiLo，手动，增量，多个GUID等），EF只有手动或SQL Server的IDENTITY;
2. NH有懒惰的属性支持（注意：不是实体，这是用于字符串，XML等属性），EF没有;
3. NH拥有二级缓存支持（相信我，企业开发人员正在使用它），而且EF没有;
4. NH支持自定义类型，甚至是复杂的，使用＆＃34; virtual＆＃34;属性，包括查询这些虚拟属性，EF不是
5. NH具有公式属性，可以是任何SQL，EF不是
6. NH具有实体和集合的自动过滤器，EF不会
7. NH支持原始类型（字符串，整数等）的集合以及组件（没有标识的复杂类型），EF不会;
8. NH支持6种集合（list，set，bag，map，array，id array），EF只支持1种;
9. NH包含一个代理生成器，可用于自定义生成的代理，EF不允许这样做;
10. NH有3个映射选项（.HBM.XML，按代码，按属性）和EF只有两个（按属性，按代码）;
11. NH允许查询和插入批处理（这是因为EF只支持IDENTITY键），EF不支持;
12. NH有几个乐观的控制策略（db上的列，包括Oracle的ORA_ROWSCN，时间戳，整数版，所有，脏列），EF只支持SQL Server＆＃39; TIMESTAMP或所有

Answer 5

这里可能值得添加，实体框架在附加断开连接的图形时会出现问题，并且缺少Nhibernate中的合并等功能。你可以用其他插件解决它，但不是开箱即用。以下是Codeplex上的功能link，要求更好地支持使用断开连接的实体，还有一些进一步的讨论。