现在,.NET v3.5 SP1已经发布(与VS2008 SP1一起发布),我们现在可以访问.NET实体框架。
我的问题是这个。当试图决定使用实体框架和LINQ to SQL作为ORM时,有什么区别?
按照我的理解,实体框架(当与LINQ to Entities一起使用时)是LINQ to SQL的“大哥”?如果是这样的话,它有什么好处?LINQ to SQL不能单独做什么?
现在,.NET v3.5 SP1已经发布(与VS2008 SP1一起发布),我们现在可以访问.NET实体框架。
我的问题是这个。当试图决定使用实体框架和LINQ to SQL作为ORM时,有什么区别?
按照我的理解,实体框架(当与LINQ to Entities一起使用时)是LINQ to SQL的“大哥”?如果是这样的话,它有什么好处?LINQ to SQL不能单独做什么?
当前回答
LINQ to SQL仅支持Microsoft SQL Server中可用的数据库表、视图、存储过程和函数的1对1映射。它是一个很好的API,可用于快速构建设计相对良好的SQL Server数据库的数据访问。LINQ2SQL首次与C#3.0和.Net Framework 3.5一起发布。
LINQ to Entities(ADO.Net Entity Framework)是一个ORM(对象关系映射器)API,它允许广泛定义对象域模型及其与许多不同ADO.Net数据提供程序的关系。因此,您可以混合和匹配许多不同的数据库供应商、应用程序服务器或协议,以设计由各种表、源、服务等构建的对象的聚合组合。ADO.Net Framework是与.Net Framework 3.5 SP1一起发布的。
这是一篇很好的MSDN入门文章:将LINQ引入关系数据
其他回答
在@lars发布的文章中,有许多明显的区别,但简短的回答是:
L2S是紧密耦合的-对象属性到数据库的特定字段,或者更正确地将对象映射到特定数据库模式L2S仅适用于SQL Server(据我所知)EF允许将单个类映射到多个表EF将处理M-M关系EF将能够针对任何ADO.NET数据提供程序
最初的前提是L2S用于快速开发,EF用于更多的“企业级”n层应用程序,但这使L2S的销售有点不足。
我在这里找到了一个非常好的答案,它解释了何时使用简单的词语:
使用哪个框架的基本经验法则是如何规划在演示层中编辑数据。Linq To Sql-如果您计划编辑一对一的表示层中数据的关系。意思是你不要计划在任何一个视图中组合来自多个表的数据或第页。实体框架-如果您计划在视图或页面中组合来自多个表的数据。制作更清楚的是,上述术语是特定于在视图或页面中操纵,而不仅仅是显示。这是重要的是要理解。使用实体框架,您可以将表格数据“合并”在一起以可编辑的形式呈现给演示层,然后提交表格后,EF将知道如何更新所有数据从各种表格中选择。可能有更准确的理由选择EF而不是L2S,但是这可能是最容易理解的。L2S没有能够合并数据以进行视图显示。
解决并发冲突
同质数据源:SQL Server仅适用于数据结构设计良好的小型项目可以在不使用SqlMetal.exe重新编译的情况下更改映射.dbml(数据库标记语言)表和类之间的一对一映射支持TPH继承不支持复杂类型存储优先方法以数据库为中心的数据库视图由C#团队创建支持但不打算进一步改进
实体框架
异构数据源:支持多个数据提供者建议用于所有新项目,以下项目除外:小型(LINQ to SQL)当数据源是平面文件(ADO.NET)时在将模型和映射文件元数据工件过程设置为复制到输出目录时,可以在不重新编译的情况下更改映射.edmx(实体数据模型),包含:SSDL(存储架构定义语言)概念模式定义语言映射规范语言表和类之间的一对一、一对多、多对一映射支持继承:TPH(每个层次的表)TPT(每种类型的表格)TPC(混凝土等级表)支持复杂类型代码优先、模型优先、存储优先的方法以应用程序为中心的数据库视图由SQL Server团队创建Microsoft Data API的未来
另请参见:
LINQ To SQL与实体框架LINQ to SQL与实体框架的区别实体框架与LINQ TO SQL
我认为快速而肮脏的答案是
LINQ to SQL是实现这一目标的快速简便的方法。这意味着如果你正在做一些小的事情,你会更快地完成任务,更快地交付。实体框架是一种全面、无限制的方法。这意味着如果你在做更大的事情,你会提前花更多的时间,发展得更慢,并且有更大的灵活性。
如果您的数据库简单明了,LINQ to SQL就可以了。如果您需要在表上添加逻辑/抽象实体,请使用实体框架。