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

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

按照我的理解,实体框架(当与LINQ to Entities一起使用时)是LINQ to SQL的“大哥”?如果是这样的话,它有什么好处?LINQ to SQL不能单独做什么?


当前回答

我在实体框架方面的经验并不出色。首先,您必须从EF基类继承,所以向POCO说再见。你的设计必须围绕EF。使用LinqtoSQL,我可以使用现有的业务对象。此外,没有延迟加载,您必须自己实现。有一些变通方法可以使用POCO和延迟加载,但它们存在IMHO,因为EF还没有准备好。我计划在4.0后重新开始

其他回答

在@lars发布的文章中,有许多明显的区别,但简短的回答是:

L2S是紧密耦合的-对象属性到数据库的特定字段,或者更正确地将对象映射到特定数据库模式L2S仅适用于SQL Server(据我所知)EF允许将单个类映射到多个表EF将处理M-M关系EF将能够针对任何ADO.NET数据提供程序

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

如果您的数据库简单明了,LINQ to SQL就可以了。如果您需要在表上添加逻辑/抽象实体,请使用实体框架。

LINQ to SQL真的死了吗?Jonathan Allen为InfoQ.com撰写

马特·沃伦(Matt Warren)将[LINQ to SQL]描述为“根本就不应该存在”的东西。从本质上讲,在真正的ORM准备就绪之前,它只是应该帮助他们开发LINQ。...实体框架的规模导致它错过了.NET 3.5/VVisual Studio 2008的最后期限。它及时完成了不幸命名为“.NET 3.5 Service Pack 1”,它更像是一个主要版本,而不是一个Service Pack。...由于复杂性,开发人员不喜欢[ADO.NET实体框架]。...从.NET 4.0开始,LINQ to Entities将是LINQ to关系场景的推荐数据访问解决方案。

解决并发冲突

同质数据源: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

两者都不支持唯一的SQL 2008数据类型。与我的观点不同的是,Entity仍然有机会在未来的某个版本中围绕我的地理数据类型构建模型,而Linq to SQL被放弃,永远不会。

不知道nHibernate或OpenAccess有什么问题。。。