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

问题描述

1. 表演


2. 速度开发


3. 整洁，直观，可维护的代码


4. 灵活性


5. 整体

我喜欢我的SQL，所以一直是ADO.NET和存储过程的死亡粉丝，但是我最近和Linq一起玩了，被吹走了写我的DataAccess图层有多快，并且决定花一些时间真正了解Linq到SQL或EF ...或者没有？

我只是想检查，这些技术中没有一个很大的缺陷，这将使我的研究时间无用。例如。性能是可怕的，对于简单的应用来说很酷，但只能带你到目前为止。

更新：
你可以专注于EF VS L2S VS SP而不是ORM VS SP。我主要感兴趣的是EF VS L2S。但是我很想让他们与存储过程进行比较，因为简单的SQl是我知道的很多。

解决方案

如果您正在启动一个新的项目，那么您可以使用Entity Framework（EF）实现更好的SQL（更像Linq to SQL），并且比Linq to SQL（L2S）更容易维护，更强大。在发布.NET 4.0之前，我认为Linq to SQL是一种过时的技术。 MS已经非常开放，不再继续进行L2S开发。

1）性能

这是很棘手的答案。对于大多数单一实体操作（ CRUD ），您将发现与所有这三项技术。您必须知道EF和Linq对SQL的工作原理，以便最充分地使用它们。对于诸如轮询查询的大量操作，您可能希望让EF / L2S编译您的实体查询，使得框架不必不断重新生成SQL，否则可能会遇到可伸缩性问题。 （请参阅编辑）

对于要更新大量数据的批量更新，原始SQL或存储过程总是比ORM解决方案更好，因为您不必须通过电线将数据组织到ORM以执行更新。

2）发展速度

在大多数情况下，EF会吹走裸机SQL /存储过程当涉及到开发速度。 EF设计人员可以在数据库更改（根据请求）时更新您的模型，因此您不会遇到目标代码和数据库代码之间的同步问题。唯一不要考虑使用ORM的时候是在做一个不进行任何更新的报告/仪表板类型的应用程序时，或者当你创建一个应用程序，只是为了在数据库上进行原始数据维护操作。

3）整洁/可维护的代码

存储过程。因为你的关系是建模的，你的代码中的联接比较少见。对于大多数查询，实体的关系对读者几乎不言而喻。没有比从层到层调试还是通过多个SQL /中间层进行更深入的了解，以了解数据实际发生的情况。 EF以非常强大的方式将您的数据模型引入您的代码。

4）灵活性

存储的过程和原始SQL更灵活 。您可以利用sprocs和SQL为奇怪的特定情况生成更快的查询，并且您可以比使用ORM更轻松地利用本机数据库功能。

5）整体

选择ORM vs的虚假二分法使用存储过程。您可以在同一个应用程序中使用这两个，您可能应该。大型批量操作应该存入存储过程或SQL（实际上由EF调用），而EF应用于您的CRUD操作和大部分中间层的需求。也许您会选择使用SQL编写报告。我猜这个故事的道德与往常一样。使用正确的工具作业。但是瘦的是，EF现在非常好（从.NET 4.0开始）。花费一些实时阅读和深入了解它，您可以轻松创建一些惊人的，高性能的应用程序。

编辑：EF 5使用自动编译的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 to SQL VS ADO.NET与存储过程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！