实体框架4和Poco和Linq2Sql性能

Question

我正在考虑使用POCO而不是自动生成实体，因为我不希望对框架有任何依赖

我想知道是否会有任何性能损失，我不确定是否必须在运行时动态代理我的实体会影响性能，

我也想知道如果我让EF4为我生成模型会更快。

我在当前的项目中关注性能很多，我已多次读过L2S如何比EF2略快但我不确定EF4，所以现在我想知道我是否会因使用EF4而出现性能问题Linq2SQL。

我真的想用POCO;这就是为什么我更喜欢EF4，但我不想再遇到性能问题。

EF4和Ling2SQL是我唯一的选择，因为我无法使用原生ADO.net或任何其他ORM，所以请从性能角度分享您对EF4和Linq2SQL的体验吗？

提前感谢。

Answer 1

如果您真的关心性能，请查看Dapper.NET。这个主页的section对各种OR框架进行了相当不错的比较，包括LINQ to SQL和Entity Framework。

一般来说，POCO是您最快的选择。 Dapper会帮助你。

仅供参考：StackOverflow使用Dapper，而StackOverflow对其生成的流量量非常 peformant。

Answer 2

最近，ADO.NET团队发布EF Power Tools以支持代码优先开发，它自动从您的模型/数据库（仅限mssql）生成POCO，并且可以完全将POCO与其他元类分开，以提供结构信息。数据库表。

在ADO.NET团队博客中，using EF Proxies如下所述

When creating instances of POCO entity types, the Entity Framework often creates instances of a dynamically generated derived type that acts as a proxy for the entity. This proxy overrides some virtual properties of the entity to insert hooks for performing actions automatically when the property is accessed.

Sometimes disabling proxy creation is useful to prevent the Entity Framework from creating proxy instances. For example, serializing non-proxy instances is considerably easier than serializing proxy instances. Proxy creation can be turned off by clearing the ProxyCreationEnabled flag.

当然，创建代理并不擅长性能，但如上所述，它只是覆盖了一些用于加载相对属性的虚拟属性，因此我认为创建代理对象而不是POCO不是问题。

Answer 3

在性能方面，我没有注意到POCO和模型/数据库之间的巨大差异。我注意到EF比Linq2Sql，Massive，PetaPoco，Ado.Net以及可能的nHibernate慢。

Answer 4

Stacker，还不确定性能，但我真的不担心。

如果你想让你的实体保持干净（就像我一样），即使是由EF生成的，你也可以使用C＃的部分类的强大功能，并拥有另一个文件（在同一个项目中，你的数据层）将实体定义再次作为部分定义，并指定此类实体实现基接口。

这种方式在另一个程序集中，称为CORE或Common或更好的Core.Interfaces ...你已经定义了所有接口，并且在应用程序堆栈的上层（业务逻辑，UI，服务等等），你总是只有针对这些接口的程序而不是DAL命名空间实体......

这为您提供了很多功能，因为一旦从db等刷新模型，如果新生成的实体破坏了已定义和通用的接口，则会立即产生编译时错误。请注意，由于您使用了部分类定义，因此您不必更改EF实体的自动生成文件中的任何内容。

希望这会有所帮助......