实体框架4.1与企业数据应用程序阻止最大性能

Question

问题范围：我想使用EF4.1而不对我知道和信任的Enterprise Library数据访问块的速度和可靠性进行任何折衷。

感谢很多关于EF性能调优的Stackoverflow链接和博客，我发布这种方式，使用与ADO / Enterprise Lib数据访问块（SqlDataReader）的性能相匹配的EF4.1。

项目： 1.没有linq到Entities / dynamic sql。我喜欢linq，我只是试着用它来反对对象。 2. 100％存储过程并且没有跟踪，没有合并，最重要的是，从不调用.SaveChanges（）。我只是调用insert / update / delete proc DbContext.StoredProcName（params）。在这一点上，我们已经消除了EF的几个快速开发元素，但它为你的存储过程自动创建一个复杂类型的方式对我来说已经足够了。

GetString和类似的方法是一个AbstractMapper，它只是遍历期望的类型并将datareader转换为类型。

所以这是我所关注的标志。我很难采用我知道的较慢的东西。

那太快了!!!慢了很多！

那更像是!! Performance Pie 根据我的结果，性能派应该会使跟踪开销增加1％以上 我试过预先编译视图，没有任何东西像没有跟踪那么大！为什么？？也许有人可以参与其中。

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

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

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

在我在新的关键任务医疗设备交付网络应用程序中实际实现这一点之前，我将非常感谢任何观察和批评。

谢谢！

Answer 1

只是一些评论：

  

Performance Pie根据我的结果，性能派应该   我试过预先将跟踪开销增加了1％以上   编译视图，没有任何东西像没有跟踪那样大大提升！   为什么？

该博客文章来自2008年，因此基于EF版本1和EntityObject派生实体。使用EF 4.1，您正在使用POCO。变更跟踪与POCO的行为完全不同。特别是当POCO对象从数据库加载到对象上下文时，Entity Framework会创建原始属性值的快照，并且存储位于上下文中。更改跟踪依赖于当前实体值与原始snapshop值之间的比较。在性能和内存消耗方面，创建此快照显然也很昂贵。我的观察结果是它的成本至少为50％（查询时间没有更改跟踪是查询时间的一半 更改跟踪）。你似乎已经衡量了更大的影响。

  

项目：1。没有linq到Entities / dynamic sql。我喜欢linq，我只是   尝试主要用它对象。 2. 100％存储过程，没有   跟踪，没有合并，最重要的是，永远不要调用.SaveChanges（）。一世   只需调用insert / update / delete proc   DbContext.StoredProcName（PARAMS）。此时我们已经淘汰了   EF的几个快速开发元素，但它自动创建的方式   存储过程的复杂类型对我来说已经足够了。

对我来说，这似乎忽略了实体框架存在的一些主要特征，并且为什么要将EF用于您的目的是值得怀疑的。如果您的主要目标是拥有一个有助于将查询结果具体化为复杂对象的工具，那么您可以查看专注于此任务的Dapper，并考虑到高性能。 （Dapper是Stackoverflow中使用的底层ORM。）

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

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