.net 实体框架与 LINQ to SQL

Entity Framework vs LINQ to SQL

提问by Chris Roberts

Now that .NET v3.5 SP1 has been released (along with VS2008 SP1), we now have access to the .NET entity framework.

现在 .NET v3.5 SP1 已经发布（与 VS2008 SP1 一起），我们现在可以访问 .NET 实体框架。

My question is this. When trying to decide between using the Entity Framework and LINQ to SQL as an ORM, what's the difference?

我的问题是这个。当试图决定使用实体框架和 LINQ to SQL 作为 ORM 时，有什么区别？

The way I understand it, the Entity Framework (when used with LINQ to Entities) is a 'big brother' to LINQ to SQL? If this is the case - what advantages does it have? What can it do that LINQ to SQL can't do on its own?

根据我的理解，实体框架（与 LINQ to Entities 一起使用时）是 LINQ to SQL 的“老大哥”？如果是这种情况 - 它有什么优势？它可以做什么 LINQ to SQL 不能单独做的事情？

采纳答案by Kris

LINQ to SQL only supports 1 to 1 mapping of database tables, views, sprocs and functions available in Microsoft SQL Server. It's a great API to use for quick data access construction to relatively well designed SQL Server databases. LINQ2SQL was first released with C# 3.0 and .Net Framework 3.5.

LINQ to SQL 仅支持 Microsoft SQL Server 中可用的数据库表、视图、sproc 和函数的 1 对 1 映射。这是一个很好的 API，可用于对设计相对良好的 SQL Server 数据库进行快速数据访问构建。LINQ2SQL 最初是随 C# 3.0 和 .Net Framework 3.5 一起发布的。

LINQ to Entities (ADO.Net Entity Framework) is an ORM (Object Relational Mapper) API which allows for a broad definition of object domain models and their relationships to many different ADO.Net data providers. As such, you can mix and match a number of different database vendors, application servers or protocols to design an aggregated mash-up of objects which are constructed from a variety of tables, sources, services, etc. ADO.Net Framework was released with the .Net Framework 3.5 SP1.

LINQ to Entities（ADO.Net 实体框架）是一个 ORM（对象关系映射器）API，它允许广泛定义对象域模型及其与许多不同 ADO.Net 数据提供者的关系。因此，您可以混合和匹配许多不同的数据库供应商、应用程序服务器或协议，以设计由各种表、源、服务等构建的对象的聚合混搭。ADO.Net Framework 与.Net 框架 3.5 SP1。

This is a good introductory article on MSDN: Introducing LINQ to Relational Data

这是 MSDN 上的一篇很好的介绍性文章： Introducing LINQ to Relational Data

回答by Brad Tutterow

I think the quick and dirty answer is that

我认为快速而肮脏的答案是

• LINQ to SQL is the quick-and-easy way to do it. This means you will get going quicker, and deliver quicker if you are working on something smaller.
• Entity Framework is the all-out, no-holds-barred way to do it. This means you will take more time up-front, develop slower, and have more flexibility if you are working on something larger.

• LINQ to SQL 是一种快速简便的方法。这意味着如果您正在处理更小的事情，您将更快地前进，并更快地交付。
• 实体框架是做到这一点的全力以赴、无拘无束的方式。这意味着如果您正在处理更大的事情，您将需要更多的前期时间，开发速度较慢，并且具有更大的灵活性。

回答by Zack Peterson

Is LINQ to SQL Truly Dead?by Jonathan Allen for InfoQ.com

LINQ to SQL 真的死了吗？乔纳森·艾伦 (Jonathan Allen) 为 InfoQ.com 撰写

Matt Warren describes [LINQ to SQL] as something that "was never even supposed to exist." Essentially, it was just supposed to be stand-in to help them develop LINQ until the real ORM was ready.

...

The scale of Entity Framework caused it to miss the .NET 3.5/Visual Studio 2008 deadline. It was completed in time for the unfortunately named ".NET 3.5 Service Pack 1", which was more like a major release than a service pack.

...

Developers do not like [ADO.NET Entity Framework] because of the complexity.

...

as of .NET 4.0, LINQ to Entities will be the recommended data access solution for LINQ to relational scenarios.

Matt Warren 将 [LINQ to SQL] 描述为“甚至不应该存在”的东西。从本质上讲，它只是帮助他们开发 LINQ，直到真正的 ORM 准备就绪。

...

Entity Framework 的规模使其错过了 .NET 3.5/Visual Studio 2008 的最后期限。它为不幸命名的“.NET 3.5 Service Pack 1”及时完成，它更像是一个主要版本而不是一个服务包。

...

由于复杂性，开发人员不喜欢 [ADO.NET 实体框架]。

...

从 .NET 4.0 开始，LINQ to Entities 将成为 LINQ to 关系场景的推荐数据访问解决方案。

回答by JamesSugrue

There are a number of obvious differences outlined in that article @lars posted, but short answer is:

@lars 发布的那篇文章中概述了许多明显的差异，但简短的回答是：

• L2S is tightly coupled - object property to specific field of database or more correctly object mapping to a specific database schema
• L2S will only work with SQL Server (as far as I know)
• EF allows mapping a single class to multiple tables
• EF will handle M-M relationships
• EF will have ability to target any ADO.NET data provider

• L2S 是紧密耦合的 - 对象属性到数据库的特定字段或更正确的对象映射到特定数据库模式
• L2S 仅适用于 SQL Server（据我所知）
• EF 允许将单个类映射到多个表
• EF会处理MM关系
• EF 将能够以任何 ADO.NET 数据提供程序为目标

The original premise was L2S is for Rapid Development, and EF for more "enterprisey" n-tier applications, but that is selling L2S a little short.

最初的前提是 L2S 用于快速开发，EF 用于更多“企业”n 层应用程序，但这对 L2S 的销售有点短。

回答by Ryszard D?egan

LINQ to SQL

LINQ 到 SQL

1. Homogeneous datasource: SQL Server
2. Recommended for small projects only where data structure is well designed
3. Mapping can be changed without recompilling with SqlMetal.exe
4. .dbml (Database Markup Language)
5. One-to-one mapping between tables and classes
6. Supports TPHinheritance
7. Doesn't support complex types
8. Storage-first approach
9. Database-centric view of a database
10. Created by C# team
11. Supported but not further improvements intended

1. 同类数据源：SQL Server
2. 仅推荐用于数据结构设计良好的小型项目
3. 无需重新编译 SqlMetal.exe 即可更改映射
4. .dbml（数据库标记语言）
5. 表和类之间的一对一映射
6. 支持TPH继承
7. 不支持复杂类型
8. 存储优先方法
9. 以数据库为中心的数据库视图
10. 由 C# 团队创建
11. 支持但不打算进一步改进

Entity Framework

实体框架

1. Heterogeneus datasource: Support many data providers
2. Recommended for all new projects except:
   • small ones (LINQ to SQL)
   • when data source is a flat file (ADO.NET)
3. Mapping can be changed without recompilling when setting model and mapping files Metadata Artifact Process to Copy To Output Directory
4. .edmx (Entity Data Model) which contains:
   • SSDL (Storage Schema Definition Language)
   • CSDL (Conceptual Schema Definition Language)
   • MSL (Mapping Specification Language)
5. One-to-one, one-to-many, many-to-one mappings between tables and classes
6. Supports inheritence:
   • TPH (Table Per Hierarchy)
   • TPT (Table Per Type)
   • TPC (Table Per Concrete Class)
7. Supports complex types
8. Code-first, Model-first, Storage-first approaches
9. Application-centric view of a database
10. Created by SQL Server team
11. Future of Microsoft Data APIs

1. 异构数据源：支持多种数据提供者
2. 推荐用于所有新项目，除了：
   • 小（LINQ to SQL）
   • 当数据源是平面文件 (ADO.NET)
3. 设置模型和映射文件时无需重新编译即可更改映射 Metadata Artifact Process to Copy To Output Directory
4. .edmx（实体数据模型），其中包含：
   • SSDL（存储架构定义语言）
   • CSDL（概念架构定义语言）
   • MSL（映射规范语言）
5. 表和类之间的一对一、一对多、多对一映射
6. 支持继承：
   • TPH（每个层次结构的表）
   • TPT（每种类型的表）
   • TPC（每个混凝土等级的表）
7. 支持复杂类型
8. 代码优先、模型优先、存储优先的方法
9. 以应用程序为中心的数据库视图
10. 由 SQL Server 团队创建
11. Microsoft 数据 API 的未来

---

---

See also:

也可以看看：

• LINQ To SQL Vs Entity Framework
• Difference between LINQ to SQL and Entity Framework
• Entity Framework vs LINQ TO SQL

• LINQ To SQL 与实体框架
• LINQ to SQL 和实体框架的区别
• 实体框架与 LINQ TO SQL

回答by Jiyosub

My experience with Entity Framework has been less than stellar. First, you have to inherit from the EF base classes, so say good bye to POCOs. Your design will have to be around the EF. With LinqtoSQL I could use my existing business objects. Additionally, there is no lazy loading, you have to implement that yourself. There are some work arounds out there to use POCOs and lazy loading, but they exist IMHO because EF isn't ready yet. I plan to come back to it after 4.0

我在实体框架方面的经验并不出色。首先，您必须从 EF 基类继承，因此告别 POCO。您的设计必须围绕 EF。使用 LinqtoSQL，我可以使用我现有的业务对象。此外，没有延迟加载，您必须自己实现。有一些解决方法可以使用 POCO 和延迟加载，但恕我直言，它们存在是因为 EF 还没有准备好。我打算在 4.0 之后回来

回答by Nawaz

I found a very good answer herewhich explains when to use what in simple words:

我在这里找到了一个很好的答案，它用简单的话解释了何时使用 what ：

The basic rule of thumb for which framework to use is how to plan on editing your data in your presentation layer.

• Linq-To-Sql- use this framework if you plan on editing a one-to-one relationship of your data in your presentation layer. Meaning you don't plan on combining data from more than one table in any one view or page.

• Entity Framework- use this framework if you plan on combining data from more than one table in your view or page. To make this clearer, the above terms are specific to data that will be manipulated in your view or page, not just displayed. This is important to understand.

With the Entity Framework you are able to "merge" tabled data together to present to the presentation layer in an editable form, and then when that form is submitted, EF will know how to update ALL the data from the various tables.

There are probably more accurate reasons to choose EF over L2S, but this would probably be the easiest one to understand. L2S does not have the capability to merge data for view presentation.

使用哪个框架的基本经验法则是如何计划在表示层中编辑数据。

• Linq-To-Sql- 如果您计划编辑表示层中数据的一对一关系，请使用此框架。这意味着您不打算在任何一个视图或页面中组合来自多个表的数据。

• 实体框架- 如果您计划在视图或页面中合并来自多个表的数据，请使用此框架。为了更清楚地说明这一点，上述术语特定于将在您的视图或页面中操作的数据，而不仅仅是显示的数据。理解这一点很重要。

使用实体框架，您可以将表格数据“合并”在一起，以可编辑的形式呈现给表示层，然后在提交该表单时，EF 将知道如何更新各种表格中的所有数据。

选择 EF 而不是 L2S 可能有更准确的理由，但这可能是最容易理解的理由。L2S 不具备合并数据以进行视图呈现的能力。

回答by terjetyl

My impression is that your database is pretty enourmous or very badly designed if Linq2Sql does not fit your needs. I have around 10 websites both larger and smaller all using Linq2Sql. I have looked and Entity framework many times but I cannot find a good reason for using it over Linq2Sql. That said I try to use my databases as model so I already have a 1 to 1 mapping between model and database.

我的印象是，如果 Linq2Sql 不符合您的需求，您的数据库非常庞大或设计得很糟糕。我有大约 10 个大大小小的网站，它们都使用 Linq2Sql。我已经多次查看实体框架，但找不到在 Linq2Sql 上使用它的充分理由。也就是说，我尝试使用我的数据库作为模型，所以我已经有了模型和数据库之间的 1 对 1 映射。

At my current job we have a database with 200+ tables. An old database with lots of bad solutions so there I could see the benefit of Entity Framework over Linq2Sql but still I would prefer to redesign the database since the database is the engine of the application and if the database is badly designed and slow then my application will also be slow. Using Entity framework on such a database seems like a quickfix to disguise the bad model but it could never disguise the bad performance you get from such a database.

在我目前的工作中，我们有一个包含 200 多个表的数据库。一个有很多糟糕解决方案的旧数据库，所以我可以看到 Entity Framework 比 Linq2Sql 的好处，但我仍然更喜欢重新设计数据库，因为数据库是应用程序的引擎，如果数据库设计不当并且速度慢，那么我的应用程序也会很慢。在这样的数据库上使用实体框架似乎是掩饰不良模型的快速修复，但它永远无法掩饰您从此类数据库中获得的糟糕性能。

回答by Omer K

You can find a good comparision here:

你可以在这里找到一个很好的比较：

http://www.dotnet-tricks.com/Tutorial/entityframework/1M5W300314-Difference-between-LINQ-to-SQL-and-Entity-Framework.html

http://www.dotnet-tricks.com/Tutorial/entityframework/1M5W300314-Difference-between-LINQ-to-SQL-and-Entity-Framework.html

http://www.c-sharpcorner.com/blogs/entity-framework-vs-linq-to-sql1

http://www.c-sharpcorner.com/blogs/entity-framework-vs-linq-to-sql1

回答by saille

The answers here have covered many of the differences between Linq2Sql and EF, but there's a key point which has not been given much attention: Linq2Sql only supports SQL Server whereas EF has providers for the following RDBMS's:

此处的答案涵盖了 Linq2Sql 和 EF 之间的许多差异，但有一个关键点并未引起太多关注：Linq2Sql 仅支持 SQL Server，而 EF 具有以下 RDBMS 的提供程序：

Provided by Microsoft:

微软提供：

• ADO.NET drivers for SQL Server, OBDC and OLE DB

• 用于 SQL Server、OBDC 和 OLE DB 的 ADO.NET 驱动程序

Via third party providers:

通过第三方供应商：

• MySQL
• Oracle
• DB2
• VistaDB
• SQLite
• PostgreSQL
• Informix
• U2
• Sybase
• Synergex
• Firebird
• Npgsql

• MySQL
• 甲骨文
• 数据库2
• 数据库
• SQLite
• PostgreSQL
• Informix
• U2
• 赛贝斯
• 协力
• 火鸟
• 数据库

to name a few.

仅举几例。

This makes EF a powerful programming abstraction over your relational data store, meaning developers have a consistent programming model to work with regardless of the underlying data store. This could be very useful in situations where you are developing a product that you want to ensure will interoperate with a wide range of common RDBMS's.

这使得 EF 成为对关系数据存储的强大编程抽象，这意味着开发人员可以使用一致的编程模型，而不管底层数据存储如何。在您开发的产品要确保与广泛的通用 RDBMS 互操作的情况下，这可能非常有用。

Another situation where that abstraction is useful is where you are part of a development team that works with a number of different customers, or different business units within an organisation, and you want to improve developer productivity by reducing the number of RDBMS's they have to become familiar with in order to support a range of different applications on top of different RDBMS's.

这种抽象有用的另一种情况是，您是与许多不同客户或组织内不同业务部门合作的开发团队的一部分，并且您希望通过减少开发人员必须成为的 RDBMS 的数量来提高他们的工作效率熟悉以便在不同的 RDBMS 之上支持一系列不同的应用程序。