实体框架 4.1 与企业数据应用程序块最高性能答案

【问题标题】：Entity Framework 4.1 vs Enterprise Data Application Block Maximum Performance实体框架 4.1 与企业数据应用程序块最高性能
【发布时间】：2011-12-27 13:14:01
【问题描述】：

问题范围：我想使用 EF4.1，而不用牺牲我知道并信任的 Enterprise Library 数据访问块的速度和可靠性。

感谢大量有关 EF 性能调整的 Stackoverflow 链接和博客，我以这种方式发布，其中很多是为了使用与 ADO/Enterprise Lib 数据访问块 (SqlDataReader) 的性能相匹配的 EF4.1。

项目： 1. 没有 linq to Entities/动态 sql。我喜欢 linq，我只是尝试将它主要用于对象。 2. 100% 存储过程，没有跟踪，没有合并，最重要的是，从不调用.SaveChanges()。我只是调用插入/更新/删除过程 DbContext.StoredProcName(params)。在这一点上，我们已经消除了 EF 的几个快速开发元素，但它为您的存储过程自动创建复杂类型的方式对我来说已经足够了。

GetString 和类似的方法是一个 AbstractMapper，它只是通过预期的类型并将数据读取器转换为类型。

所以就我而言，这是要击败的标志。采用我知道速度较慢的东西会很困难。

那就更慢了！！！慢很多！

这更像！！ Performance Pie 根据我的结果，性能派应该会增加超过 1% 的跟踪开销我尝试预编译视图，没有什么比没有跟踪更重要的了！为什么？？也许有人可以插话。

因此，与 Enterprise Lib 相比，这并不公平，但我正在对数据库进行一次不定时调用以加载我理解的元数据，每个 IIS 应用程序池加载一次。基本上在您的应用生命周期中一次。

我以这种方式将 EF 用于自动存储过程生成，并使用 Linq to Edmx 自动导入所有这些 edmx 函数节点以映射到实体。然后我为每个实体和一个引擎自动生成一个存储库。

由于我从不调用 SaveChanges，所以我不会花时间映射到设计器中的存储过程。这需要很长时间，而且很容易打破它而不知道它。所以我只是从上下文中调用 procs。

在我在我的新任务关键型医疗设备交付 Web 应用程序中实际实现这一点之前，我希望得到任何意见和批评。

谢谢！

【问题讨论】：

我已经使用它几个月了，它工作得很好，但只有一件事。 EF 不是源代码控制或合并友好。如果有人对 EF 持怀疑态度，我确实认为性能不是主要问题。EF 更新整个 .edmx 并将图表 xy 位置存储在 .edmx 中，这使得文件极难合并。我什至有注意到除了两个不同的开发人员之外，相同的未更改的 xml 节点出现了数千行。 Code Smith 用 PlinqO 解决了这个问题，MS 也应该解决这个问题。

标签： entity-framework-4.1 enterprise-library

【解决方案1】：

简单说几句：

Performance Pie根据我的结果，性能派应该将跟踪开销增加了超过 1% 我尝试过 pre 编译视图，没有什么比没有跟踪更重要的了！为什么？？

这篇博文来自 2008 年，因此基于 EF 版本 1 和 EntityObject 派生实体。使用 EF 4.1，您正在使用 POCO。 POCO 的更改跟踪行为非常不同。特别是当 POCO 对象从数据库加载到对象上下文中时，实体框架会创建原始属性值的快照并存储在上下文中。更改跟踪依赖于当前实体值和原始 snapshop 值之间的比较。创建此快照在性能和内存消耗方面显然也很昂贵。我的观察是它至少要花费 50%（查询时间没有更改跟踪是查询时间的一半有更改跟踪）。你似乎测出了更大的影响。

项目： 1. 没有 linq to Entities/动态 sql。我爱 linq，我只是尝试将其主要用于对象。 2. 100% 存储过程并且没有跟踪，不合并，最重要的是，永远不要调用 .SaveChanges()。一世只需调用插入/更新/删除过程 DbContext.StoredProcName（参数）。至此我们已经消除了 EF 的几个快速开发元素，但它自动创建的方式存储过程的复杂类型对我来说就足够了。

对我来说，这看起来您基本上忽略了实体框架存在的一些主要功能，并且您为什么要使用 EF 来实现您的目的是有问题的。如果您的主要目标是拥有一个有助于将查询结果具体化为复杂对象的工具，您可以查看Dapper，它专注于以高性能为目标的任务。（Dapper 是 Stackoverflow 使用的底层 ORM。）

几天前这里有一个关于 EF 性能的很好答案的问题。现在已迁移到“程序员”：

https://softwareengineering.stackexchange.com/questions/117357/is-entity-framework-suitable-for-high-traffic-websites

【讨论】：

很好的信息！谢谢你的文章。我正在调查这一切。我从数据库返回动态的简短经验是，当我输入错误的属性以及提取强类型对象时，我的应用程序在编译时没有中断，感觉就像双重映射，我继续前进。我应该重温 Dapper 和 Massive。我可能只是为 Enterprise 编写自动代码生成器。再次，很棒的信息！谢谢。