实体框架与ADO.NET

在ASP.NET MVC3项目中，使用实体框架（使用存储库模式）还是使用ADO.NET与SqlConnection和SqlCommand更快，更安全？实体框架与ADO.NET

2012-03-21 Travis J

这个问题很模糊，并且会更适合程序员.stackexchange.com，因为没有代码特定的答案。 – 2012-03-21 19:05:23

@ErikPhilips - 你使用EF吗？ – 2012-03-21 19:12:57

**是** - 作为程序员使用EF的速度会更快 - 它会隐藏您的很多实现细节，所以学习的次数少，掌握的次数少。 ** **是** - 使用原始ADO.NET在运行时性能方面会更快，因为EF实际上是ADO.NET之上的一个层 - 并且每个附加层都会耗费一些运行时性能。但是：只要实体框架的运行时性能足够好，足以满足您的应用程序的需求，那么通过使用原始ADO.NET就可以缩短所有开发时间以挤出更多的运行时性能，这真的没有意义 - EF的性能很好足够**！ – 2012-03-21 21:37:31

非常笼统的问题，但一些想法。

性能：当它涉及到性能，只要所有的开发者有线索

平原的SqlCommand和DataReader将显著加快。使用.net 4.5和EF 5时，EF似乎会获得不错的性能提升，但普通的sql总是会更快。

在这里看到一些数字：http://blogs.msdn.com/b/adonet/archive/2012/02/14/sneak-preview-entity-framework-5-0-performance-improvements.aspx

平原ADO.NET也支持这可能是在某些情况下非常重要的异步图案。 EF不。 ATLEAST不是EF 4.

安全

平原SQL可能只要您使用paramaterized查询像EF一样安全。 EF将自动执行此操作，以防止SQL注入。因为EF总是给你这个，所以我会认为它更安全，但略有余量。

可测

我发现这是一个巨大的胜利，当涉及到EF。与其嘲笑嘲笑，我使用SqlCe4对我的控制器执行快速集成测试。只要您使用EF，就很容易做到这一点。

摘要

我发现EF非常有能力和API是令人愉快的工作。如果你在做性能密集型的事情，你将不得不放入原始的SqlDataReader和SqlBulkCopy中，但是混合它们不是问题。我喜欢使用EF，因为我的工作效率更高，我可以忍受性能损失。在哪里我感受到大的冲击，我将使用普通的Sql。

来源

2012-03-21 19:42:45

好帖子，但外部表现的效果真的没有帮助。我的意思是在4ms查询时长度是23ms。这并不是很明显。而更加没有意义的是速度差异并不是由于SQL性能，而是由SQL生成的。因此，通常需要4秒运行的查询不会长达23倍（92秒）。这绝不意味着对你的帖子发表评论，但是如果做正确的数据收集（微软显然没有这样做）是很复杂的。 – 2012-03-21 20:06:47

问题在于你在考虑服务器时。放置23倍以上的cpu（或4倍于EF5）是一个相当重要的可伸缩性问题（在某些情况下）。我的观点实际上是：使用EF，其中较慢的perf不会成为问题。但是如果需要的话，准备好测量并下载到ADO.NET。 – 2012-03-21 20:59:34

我认为如果你去实体框架，它会为你节省一些开发时间，因为它会为你生成大部分的代码。但对于使用SQlConnection和SQLCommand的ADO.NET，您需要编写自己的数据访问层的创建/更新/删除方法。

我认真地认为使用ADO.NET存储过程提供了一些性能优势，因为执行计划存储在服务器中。

执行SQL语句时，数据库必须为其生成执行计划。如果该SQL语句反复运行，则每执行一次该数据库可能都必须重新生成查询的执行计划。在SQL经常运行的这些情况下，将SQL移动到存储过程可以提供更高的性能（而不是提到更高的安全性）。第一次执行存储过程时，数据库将生成一个查询执行计划，将该计划存储在过程高速缓存中，然后执行该存储过程。在随后调用存储过程时，仅数据库引擎必须从过程高速缓存中获取查询计划，并重新运行存储过程。因此，它跳过制定的查询计划对后续调用

http://msdn.microsoft.com/en-us/magazine/cc163799.aspx

来源

2012-03-21 19:06:51 Shyju

EF和纯ADO.NET有很大的性能差异。 EF执行时间较慢，但在开发时间上要快很多。 – 2012-03-21 19:34:17

@WouterdeKort：同意。我更新了我的答案以包含您的观点。 – Shyju 2012-03-21 19:41:53

我同时使用取决于项目需要的步骤。这是我的看法：

好（很暧昧）

在这种情况下我会定义为一个产品/功能，它为我提供了一种方式来创建用更少的代码的解决方案写出更好的，少跑时间错误检测，以及更多功能。

在这方面，实体框架（EF）为我提供了插入/更新/删除语句，强类型模型以及创建动态强类型sql语句的方法。

更快

EF较慢，这取决于你的经验/知识，也可以是几百倍慢。有了如何使用EF的正确知识，速度差异可以忽略不计。

安全

无论ADO也不EF提供任何手段的安全性（据我所知）。安全性通常在演示文稿（IIS，Winforms等）和/或SQL服务器上进行控制。

我使用EF发现（也许我还没有找到解决方案）的唯一主要的限制是无法为它强类型的更新记录，如：

UPDATE [sometable] 
SET [column1] = 'new value' 
WHERE [column2] = 'shared ID value'

哪里，取决于重用这种方法，我要么使用SqlCommand或写一个存储过程。从第一个评论

更新在关于存储过程，实体框架（EF）是非常成熟的，在这一点上，不仅可以存储过程从EF调用，但每个模型的数据的方法（选择，插入，更新，删除）可以映射到存储过程。我没有亲自做过，但它绝对是框架的一部分。

至于从安全角度调用存储过程，存储过程安全性存储在SQL服务器上。如果它不能从EF调用，那么它将无法从SqlCommand中调用。

来源

2012-03-21 19:27:06

我会从问题中移除得更好，你是正确的，因为它很模糊。速度是一个主要问题，所以我很高兴听到你说那里没有太大的差别。至于安全性，我的理解是EF不能使用存储过程，因此会引发安全问题。感谢您的输入。 – 2012-03-21 19:35:48

根据您对存储过程的评论更新。 – 2012-03-21 19:39:54

实体框架与ADO.NET

回答

相关问题