实体框架VS LINQ到SQL VS ADO.NET使用存储过程？ [英] Entity Framework VS LINQ to SQL VS ADO.NET with stored procedures?

问题描述

您如何评价他们每个人而言：

1. 性能
2. 发展速度
3. 整洁，直观，易于维护的code
4. 灵活性
5. 在总体

我喜欢我的SQL等一直是ADO.NET的铁杆粉丝和存储过程，但我最近有一出戏与LINQ to SQL和由我是如何迅速地写出我的数据访问层的交口称赞，并有决定花一些时间真正理解或者LINQ到SQL或EF ...或者都不是？

我只是想检查一下，有没有在任何这些技术，将会使我的研究时间没用很大的缺陷。例如。性能是可怕的，它的凉爽简单的应用程序，但也只能带你这么远。<​​/ P>

更新： 您可以专注于EF VS L2S VS的SP，而不是ORM VS的SP。我主要是由EF VS L2S感兴趣。但我渴望有他们相比对存储的特效太多，因为普通的SQL是我很了解。

解决方案

首先，如果你开始一个新的项目，去与实体框架（EF） - 现在会产生更好的SQL（更像LINQ到SQL那样），更易于维护，比LINQ到SQL（L2S）更强大。随着.NET 4.0的发布，我认为LINQ到SQL是一种过时的技术。 MS已经非常开放的对不持续L2S发展更进一步。

1）性能

这是棘手的回答。对于大多数单一实体操作（ CRUD ），你会发现几乎相同的性能与所有三种技术。你必须知道如何EF和LINQ to SQL工作，以利用它们以最充分的。对于像查询查询，大批量操作，您可能希望有EF / L2S编译你的实体的查询，使框架没有必须不断重新生成SQL，或者你可以遇到可扩展性问题。 （见编辑）

对于您正在更新数据，原始的SQL语句或存储过程中大量将始终执行不是一个ORM解决方案更好，因为你不必在传输的数据元帅的ORM来执行更新批量更新。

发展 2）速度

在大多数情况下，英孚将吹走赤裸裸的SQL /存储的特效，当涉及到发展的速度。 EF英孚设计人员可以从数据库更新模式，因为它的变化（根据要求）​​，这样你就不会遇到之间你的对象code和数据库code同步问题。我不会考虑使用ORM唯一的一次是当你在做一个报告/仪表板类型的应用程序，你没有做任何更新，或当你创建一个应用程序只是做原始数据维护操作上的数据库。

3）整齐/维护的code

相传，EF击败SQL /存储过程。因为你的关系进行建模，加入在code是比较罕见的。各实体的关系几乎是不言自明的读者对于大多数查询。没有什么比从一线转到层调试或通过多个SQL /中间层，以了解发生了什么实际上发生在你的数据更差。 EF将您的数据模型到code在一个非常有力的方式。

4）灵活性

存储的特效和原始SQL更加灵活。你可以利用存储过程和SQL，生成奇特定情况下更快的查询，并可以利用本地数据库功能比你可以用和ORM更加容易。

5）整体

不要陷入在错误的二分法。您可以在同一应用程序同时使用，你可能应该。大批量操作应该在存储过程或SQL（这实际上可以由EF被调用）和EF应该用于您的CRUD操作和大部分的中间层的需求。也许你会选择使用SQL编写的报告。我想这个故事的寓意是相同的，因为它一直都是。使用正确的工具来完成工作。但它的骨感，EF很好时下（作为.NET 4.0）。多花一些时间来阅读和理解它的深度，你可以创造一些令人惊叹的，高性能的应用程序提供方便。

修改：EF 5简化这部分有点与<一个href="http://blogs.msdn.com/b/efdesign/archive/2011/06/30/auto-compiled-linq-queries-entity-framework-june-2011-ctp.aspx">auto-compiled LINQ查询，但真正大批量的东西，你一定会需要测试并分析一下在现实世界中最适合你。

How would you rate each of them in terms of:

1. Performance
2. Speed of development
3. Neat, intuitive, maintainable code
4. Flexibility
5. Overall

I like my SQL and so have always been a die-hard fan of ADO.NET and stored procedures but I recently had a play with Linq to SQL and was blown away by how quickly I was writing out my DataAccess layer and have decided to spend some time really understanding either Linq to SQL or EF... or neither?

I just want to check, that there isn't a great flaw in any of these technologies that would render my research time useless. E.g. performance is terrible, it's cool for simple apps but can only take you so far.

Update: Can you concentrate on EF VS L2S VS SPs rather than ORM VS SPs. I'm mainly interested by EF VS L2S. But am keen to have them compared against stored procs too since plain SQl is something I know a lot about.

解决方案

First off, if you're starting a new project, go with Entity Framework ("EF") - it now generates much better SQL (more like Linq to SQL does) and is easier to maintain and more powerful than Linq to SQL ("L2S"). As of the release of .NET 4.0, I consider Linq to SQL to be an obsolete technology. MS has been very open about not continuing L2S development further.

1) Performance

This is tricky to answer. For most single-entity operations (CRUD) you will find just about equivalent performance with all three technologies. You do have to know how EF and Linq to SQL work in order to use them to their fullest. For high-volume operations like polling queries, you may want to have EF/L2S "compile" your entity query such that the framework doesn't have to constantly regenerate the SQL, or you can run into scalability issues. (see edits)

For bulk updates where you're updating massive amounts of data, raw SQL or a stored procedure will always perform better than an ORM solution because you don't have to marshal the data over the wire to the ORM to perform updates.

2) Speed of Development

In most scenarios, EF will blow away naked SQL/stored procs when it comes to speed of development. The EF designer can update your model from your database as it changes (upon request), so you don't run into synchronization issues between your object code and your database code. The only time I would not consider using an ORM is when you're doing a reporting/dashboard type application where you aren't doing any updating, or when you're creating an application just to do raw data maintenance operations on a database.

3) Neat/Maintainable code

Hands down, EF beats SQL/sprocs. Because your relationships are modeled, joins in your code are relatively infrequent. The relationships of the entities are almost self-evident to the reader for most queries. Nothing is worse than having to go from tier to tier debugging or through multiple SQL/middle tier in order to understand what's actually happening to your data. EF brings your data model into your code in a very powerful way.

4) Flexibility

Stored procs and raw SQL are more "flexible". You can leverage sprocs and SQL to generate faster queries for the odd specific case, and you can leverage native DB functionality easier than you can with and ORM.

5) Overall

Don't get caught up in the false dichotomy of choosing an ORM vs using stored procedures. You can use both in the same application, and you probably should. Big bulk operations should go in stored procedures or SQL (which can actually be called by the EF), and EF should be used for your CRUD operations and most of your middle-tier's needs. Perhaps you'd choose to use SQL for writing your reports. I guess the moral of the story is the same as it's always been. Use the right tool for the job. But the skinny of it is, EF is very good nowadays (as of .NET 4.0). Spend some real time reading and understanding it in depth and you can create some amazing, high-performance apps with ease.

EDIT: EF 5 simplifies this part a bit with auto-compiled LINQ Queries, but for real high volume stuff, you'll definitely need to test and analyze what fits best for you in the real world.

这篇关于实体框架VS LINQ到SQL VS ADO.NET使用存储过程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！