首先，如果您要开始一个新项目，请使用 Entity Framework (“EF”) - 它现在生成更好的 SQL（更像 Linq to SQL 所做的），并且比 Linq to SQL 更容易维护且更强大（“ L2S”）。自 .NET 4.0 发布以来，我认为 Linq to SQL 是一种过时的技术。 MS 对于不再继续进一步开发 L2S 持非常开放的态度。
1) 性能
这个问题很难回答。对于大多数单实体操作（CRUD），您会发现与所有这三种技术。您必须了解 EF 和 Linq to SQL 的工作原理才能充分利用它们。对于轮询查询等大容量操作，您可能希望让 EF/L2S“编译”您的实体查询，以便框架不必不断重新生成 SQL，否则您可能会遇到可扩展性问题。 （请参阅编辑）
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.
Substantial amount of "repeating yourself" while specifying the same table and field names. The high chance of breaking the application after renaming a DB entity and missing some references to it somewhere.
Slow development
ORM:
(+)
Rapid development
Data access code now under source control
You're isolated from changes in DB. If that happens you only need to update your model/mappings in one place.
(-)
Performance may be worse
No or little control over SQL the ORM produces (could be inefficient or worse buggy). Might need to intervene and replace it with custom stored procedures. That will render your code messy (some LINQ in code, some SQL in code and/or in the DB out of source control).
As any abstraction can produce "high-level" developers having no idea how it works under the hood
The general tradeoff is between having a great flexibility and losing lots of time vs. being restricted in what you can do but having it done very quickly.
There is no general answer to this question. It's a matter of holy wars. Also depends on a project at hand and your needs. Pick up what works best for you.
LINQ-to-SQL is a remarkable piece of technology that is very simple to use, and by and large generates very good queries to the back end. LINQ-to-EF was slated to supplant it, but historically has been extremely clunky to use and generated far inferior SQL. I don't know the current state of affairs, but Microsoft promised to migrate all the goodness of L2S into L2EF, so maybe it's all better now.
Personally, I have a passionate dislike of ORM tools (see my diatribe here for the details), and so I see no reason to favour L2EF, since L2S gives me all I ever expect to need from a data access layer. In fact, I even think that L2S features such as hand-crafted mappings and inheritance modeling add completely unnecessary complexity. But that's just me. ;-)
There is a whole new approach that you may want to consider if what you're after is the power and performance of stored procedures, and the rapid development that tools like Entity Framework provide.
I've taken SQL+ for a test drive on a small project, and it is really something special. You basically add what amounts to comments to your SQL routines, and those comments provide instructions to a code generator, which then builds a really nice object oriented class library based on the actual SQL routine. Kind of like entity framework in reverse.
Input parameters become part of an input object, output parameters and result sets become part of an output object, and a service component provides the method calls.
If you want to use stored procedures, but still want rapid development, you might want to have a look at this stuff.
发布评论
评论（5）
首先，如果您要开始一个新项目，请使用 Entity Framework (“EF”) - 它现在生成更好的 SQL（更像 Linq to SQL 所做的），并且比 Linq to SQL 更容易维护且更强大（“ L2S”）。自 .NET 4.0 发布以来，我认为 Linq to SQL 是一种过时的技术。 MS 对于不再继续进一步开发 L2S 持非常开放的态度。
1) 性能
这个问题很难回答。对于大多数单实体操作（CRUD），您会发现与所有这三种技术。您必须了解 EF 和 Linq to SQL 的工作原理才能充分利用它们。对于轮询查询等大容量操作，您可能希望让 EF/L2S“编译”您的实体查询，以便框架不必不断重新生成 SQL，否则您可能会遇到可扩展性问题。 （请参阅编辑）
对于要更新大量数据的批量更新，原始 SQL 或存储过程将始终比 ORM 解决方案执行得更好，因为您不必通过网络将数据编组到 ORM 来执行更新。
2) 开发速度
在大多数情况下，EF 在开发速度方面将击败裸 SQL/存储过程。 EF 设计器可以在数据库发生变化时（根据请求）更新模型，这样您就不会遇到对象代码和数据库代码之间的同步问题。我唯一不会考虑使用 ORM 的情况是，当您正在执行不进行任何更新的报告/仪表板类型应用程序时，或者当您创建一个应用程序只是为了对数据库执行原始数据维护操作时。
3) 整洁/可维护的代码
毫无疑问，EF 击败了 SQL/sprocs。由于您的关系是建模的，因此代码中的联接相对较少。对于大多数查询，实体的关系对于读者来说几乎是不言而喻的。没有什么比必须逐层调试或通过多个 SQL/中间层才能了解数据实际发生的情况更糟糕的了。 EF 以非常强大的方式将数据模型带入代码中。
4）灵活性
存储过程和原始SQL更加“灵活”。您可以利用存储过程和 SQL 为奇怪的特定情况生成更快的查询，并且您可以比使用 ORM 更轻松地利用本机数据库功能。
5) 总体
不要陷入选择 ORM 与使用存储过程的错误二分法。您可以在同一个应用程序中使用这两种方法，而且您可能应该这样做。大批量操作应该放在存储过程或 SQL（实际上可以由 EF 调用）中，并且 EF 应该用于您的 CRUD 操作和大多数中间层的需求。也许您会选择使用 SQL 来编写报告。我想这个故事的寓意和以往一样。使用适合工作的正确工具。但最重要的是，EF 如今非常好（从 .NET 4.0 开始）。花一些时间实时阅读并深入理解它，您可以轻松创建一些令人惊叹的高性能应用程序。
编辑：EF 5 使用 自动编译的 LINQ 查询，但对于真正的大容量内容，您肯定需要测试和分析现实世界中最适合您的内容。
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.
存储过程：
(+)
(-)
ORM：
(+)
(-)
一般的权衡是在拥有很大的灵活性和浪费大量时间与受到限制但可以很快完成之间进行。
这个问题没有通用的答案。这是圣战的问题。还取决于手头的项目和您的需求。选择最适合您的方法。
Stored procedures:
(+)
(-)
ORM:
(+)
(-)
The general tradeoff is between having a great flexibility and losing lots of time vs. being restricted in what you can do but having it done very quickly.
There is no general answer to this question. It's a matter of holy wars. Also depends on a project at hand and your needs. Pick up what works best for you.
你的问题基本上是 O/RM 与手写 SQL
使用 ORM 还是纯 SQL？
看看其他一些 O/RM 解决方案，L2S 并不是唯一的解决方案（NHibernate、ActiveRecord）
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
来解决具体问题：
your question is basically O/RM's vs hand writing SQL
Using an ORM or plain SQL?
Take a look at some of the other O/RM solutions out there, L2S isn't the only one (NHibernate, ActiveRecord)
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
to address the specific questions:
LINQ-to-SQL 是一项出色的技术，使用起来非常简单，并且总的来说会生成非常好的后端查询。 LINQ-to-EF 原本打算取代它，但从历史上看，它使用起来极其笨拙，并且生成的 SQL 质量也差得多。我不知道目前的情况，但微软承诺将 L2S 的所有优点迁移到 L2EF 中，所以也许现在一切都更好了。
就我个人而言，我非常不喜欢 ORM 工具（请参阅我的诽谤 此处了解详细信息），因此我认为没有理由支持 L2EF，因为 L2S 为我提供了我期望从数据访问层获得的一切。事实上，我什至认为 L2S 功能（例如手工映射和继承建模）增加了完全不必要的复杂性。但这只是我。 ;-)
LINQ-to-SQL is a remarkable piece of technology that is very simple to use, and by and large generates very good queries to the back end. LINQ-to-EF was slated to supplant it, but historically has been extremely clunky to use and generated far inferior SQL. I don't know the current state of affairs, but Microsoft promised to migrate all the goodness of L2S into L2EF, so maybe it's all better now.
Personally, I have a passionate dislike of ORM tools (see my diatribe here for the details), and so I see no reason to favour L2EF, since L2S gives me all I ever expect to need from a data access layer. In fact, I even think that L2S features such as hand-crafted mappings and inheritance modeling add completely unnecessary complexity. But that's just me. ;-)
如果您追求的是存储过程的功能和性能，以及实体框架等工具提供的快速开发，那么您可能需要考虑一种全新的方法。
我在一个小项目中试用了 SQL+，它确实很特别。您基本上将相当于注释的内容添加到 SQL 例程中，这些注释为代码生成器提供指令，然后代码生成器基于实际的 SQL 例程构建一个非常好的面向对象的类库。有点像相反的实体框架。
输入参数成为输入对象的一部分，输出参数和结果集成为输出对象的一部分，并且服务组件提供方法调用。
如果您想使用存储过程，但仍希望快速开发，您可能想看看这个东西。
There is a whole new approach that you may want to consider if what you're after is the power and performance of stored procedures, and the rapid development that tools like Entity Framework provide.
I've taken SQL+ for a test drive on a small project, and it is really something special. You basically add what amounts to comments to your SQL routines, and those comments provide instructions to a code generator, which then builds a really nice object oriented class library based on the actual SQL routine. Kind of like entity framework in reverse.
Input parameters become part of an input object, output parameters and result sets become part of an output object, and a service component provides the method calls.
If you want to use stored procedures, but still want rapid development, you might want to have a look at this stuff.