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

问题描述

你如何评价他们每个人:

How would you rate each of them in terms of:

1. 性能
2. 发展速度
3. 简洁、直观、可维护的代码
4. 灵活性
5. 总体

我喜欢我的 SQL，因此一直是 ADO.NET 和存储过程的铁杆粉丝，但我最近玩了 Linq to SQL，被我写出 DataAccess 层的速度之快所震撼，并拥有决定花一些时间真正了解 Linq to SQL 或 EF……还是两者都不了解?

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.

更新:您能否专注于 EF VS L2S VS SP 而不是 ORM VS SP.我主要对 EF VS L2S 感兴趣.但是我也很想将它们与存储过程进行比较，因为我非常了解普通的 SQl.

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.

推荐答案

首先，如果您要开始一个新项目，请使用 Entity Framework ("EF") - 它现在可以生成更好的 SQL(更像是 LinqSQL 确实如此)并且比 Linq to SQL(L2S")更易于维护且功能更强大.在 .NET 4.0 发布时，我认为 Linq to SQL 是一种过时的技术.MS 对不再继续 L2S 开发持非常开放的态度.

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) 性能

这很难回答.对于大多数单实体操作(CRUD)，您会发现与所有三种技术.您必须了解 EF 和 Linq to SQL 的工作原理才能充分利用它们.对于轮询查询等大容量操作，您可能希望 EF/L2S 编译"您的实体查询，这样框架就不必不断地重新生成 SQL，否则您可能会遇到可伸缩性问题.(见编辑)

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)

对于要更新大量数据的批量更新，原始 SQL 或存储过程的性能总是比 ORM 解决方案更好，因为您不必通过线路将数据编组到 ORM 来执行更新.

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) 开发速度

在大多数情况下，在开发速度方面，EF 会淘汰裸 SQL/存储过程.EF 设计器可以在您的数据库更改时(根据请求)更新您的模型，因此您不会遇到对象代码和数据库代码之间的同步问题.唯一一次我不会考虑使用 ORM 的情况是，当您在不进行任何更新的情况下执行报告/仪表板类型的应用程序时，或者当您创建应用程序只是为了对数据库进行原始数据维护操作时.

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) 整洁/可维护的代码

毫无疑问，EF 击败了 SQL/sprocs.因为您的关系是建模的，所以代码中的连接相对较少.对于大多数查询，实体的关系对读者来说几乎是不言而喻的.没有什么比不得不逐层调试或通过多个 SQL/中间层来了解数据实际发生的情况更糟糕的了.EF 以一种非常强大的方式将您的数据模型带入您的代码中.

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) 灵活性

存储过程和原始 SQL 更加灵活".您可以利用 sprocs 和 SQL 为奇怪的特定情况生成更快的查询，并且您可以比使用 ORM 更容易地利用本机 DB 功能.

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) 总体

不要陷入选择 ORM 与使用存储过程的错误二分法.您可以在同一个应用程序中同时使用这两种方法，而且您可能应该这样做.大批量操作应该进入存储过程或 SQL(实际上可以由 EF 调用)，并且 EF 应该用于您的 CRUD 操作和大多数中间层的需求.也许您会选择使用 SQL 来编写报告.我想这个故事的寓意和往常一样.为工作使用正确的工具.但最重要的是，EF 现在非常好(从 .NET 4.0 开始).花一些时间阅读和深入理解它，您可以轻松创建一些令人惊叹的高性能应用程序.

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.

编辑:EF 5 使用 自动编译的 LINQ 查询，但对于真正的大容量内容，您肯定需要测试和分析最适合您的现实世界.

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屋！