实体框架4以及Poco和Linq2Sql的性能
本文关键字：Linq2Sql 性能 Poco 框架 以及 实体 | 更新日期: 2023-09-27 17:59:13
我正在考虑使用POCO而不是自动生成实体，因为我不希望对框架有任何依赖
我想知道这是否会影响性能，我不确定在运行时动态代理我的实体是否会影响的性能
我还想知道如果我让EF4为我生成模型，它是否会更快。
在我目前的项目中，我非常关心性能，我读过很多次关于L2S如何比EF2稍快的文章，但我不确定EF4，所以现在我想知道使用EF4而不是Linq2SQL是否会出现性能问题。
我真的很想使用POCO；这就是为什么我更喜欢EF4，但我不想有性能问题。
EF4和Ling2SQL是我唯一的选择，因为我不能使用本机ADO.net或任何其他ORM，所以你能从性能的角度分享你对EF4和林q2SQL的经验吗？
提前谢谢。
如果您真的很关心性能，可以看看Dapper。NET。他们主页的这一部分对各种OR框架进行了相当不错的比较，包括LINQ到SQL和实体框架。
一般来说，POCO是您最快的选择。Dapper会帮你的。
仅供参考：Dapper由StackOverflow使用，而StackOverload对于其产生的流量来说是惊人的性能。
最近，ADO。NET团队发布了EF Power Tools来支持代码优先开发，它自动从您的模型/数据库中生成POCO（仅限mssql），并可以将POCO与其他元类完全分离，以提供数据库表的结构信息。
在ADO。NET团队博客，使用EF代理如下
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不是问题。
我没有注意到POCO和模型/数据库之间在性能方面的巨大差异。我注意到EF比Linq2Sql、Massive、PetaPoco、Ado慢。Net，可能还有nHibernate。
Stacker，目前还不确定性能，但我并不担心。
如果你想保持你的实体干净（就像我所做的那样），即使是由EF生成的，你也可以使用C#的分部类的力量，并有另一个文件（在同一个项目中，你的数据层），在那里你可以将实体定义为分部，并指定这样的实体实现你的基本接口。
这种方式在另一个程序集中，称为类似CORE或Common或更好的CORE。接口。。。你已经定义了所有接口，在应用程序堆栈的上层（业务逻辑、UI、服务等），你总是并且只针对这些接口而不是DAL名称空间实体进行编程。。。
这给了你很大的力量，因为一旦你从数据库刷新模型等等，如果新生成的实体破坏了定义的和通用的接口，你会立即得到一个编译时错误。请注意，由于使用了分部类定义，因此不必在EF实体的自动生成文件中更改任何内容。
希望这能帮助。。。