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

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

按照我的理解,实体框架(当与LINQ to Entities一起使用时)是LINQ to SQL的“大哥”?如果是这样的话,它有什么好处?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关系场景的推荐数据访问解决方案。

其他回答

我正在为一个使用Linq to SQL的大型项目的客户工作。当项目开始时,这是一个明显的选择,因为当时实体框架缺乏一些主要功能,Linq to SQL的性能要好得多。

现在EF已经进化,Linq to SQL缺少异步支持,这对于高度可扩展的服务非常有用。我们有时每秒有100多个请求,尽管我们已经优化了数据库,但大多数查询仍然需要几毫秒才能完成。由于同步数据库调用,线程被阻塞,无法用于其他请求。

我们正考虑切换到实体框架,仅用于此功能。遗憾的是,微软没有在Linq to SQL中实现异步支持(或者开源,所以社区可以这样做)。

2018年12月补遗:微软正在向.NET Core迁移,而Linq-2-SQL在.NET Core上不受支持,因此您需要迁移到EF,以确保将来可以迁移到EF.Core。

还有一些其他选项需要考虑,例如LLBLGen。它是一个成熟的ORM解决方案,已经存在了很长时间,并且已经被证明比MS数据解决方案(ODBC、ADO、ADO.NET、Linq-2-SQL、EF、EF.core)更具未来性。

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

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

在我目前的工作中,我们有一个拥有200多个表的数据库。一个有很多糟糕解决方案的旧数据库,因此我可以看到实体框架优于Linq2Sql的好处,但我还是希望重新设计数据库,因为数据库是应用程序的引擎,如果数据库设计糟糕且速度慢,那么我的应用程序也会很慢。在这样的数据库上使用Entity框架似乎是一种快速修复方法,可以掩盖坏模型,但它永远无法掩盖从这样的数据库中获得的糟糕性能。

这里有一些指标。。。(量化事物!!!)

我在使用实体框架的地方进行了这个查询

var result = (from metattachType in _dbContext.METATTACH_TYPE
                join lineItemMetattachType in _dbContext.LINE_ITEM_METATTACH_TYPE on metattachType.ID equals lineItemMetattachType.METATTACH_TYPE_ID
                where (lineItemMetattachType.LINE_ITEM_ID == lineItemId && lineItemMetattachType.IS_DELETED == false
                && metattachType.IS_DELETED == false)
                select new MetattachTypeDto()
                {
                    Id = metattachType.ID,
                    Name = metattachType.NAME
                }).ToList();

并将其更改为我使用的存储库模式Linq公司

            return await _attachmentTypeRepository.GetAll().Where(x => !x.IsDeleted)
                .Join(_lineItemAttachmentTypeRepository.GetAll().Where(x => x.LineItemId == lineItemId && !x.IsDeleted),
                attachmentType => attachmentType.Id,
                lineItemAttachmentType => lineItemAttachmentType.MetattachTypeId,
                (attachmentType, lineItemAttachmentType) => new AttachmentTypeDto
                {
                    Id = attachmentType.Id,
                    Name = attachmentType.Name
                }).ToListAsync().ConfigureAwait(false);

Linq到sql

            return (from attachmentType in _attachmentTypeRepository.GetAll()
                    join lineItemAttachmentType in _lineItemAttachmentTypeRepository.GetAll() on attachmentType.Id equals lineItemAttachmentType.MetattachTypeId
                    where (lineItemAttachmentType.LineItemId == lineItemId && !lineItemAttachmentType.IsDeleted && !attachmentType.IsDeleted)
                    select new AttachmentTypeDto()
                    {
                        Id = attachmentType.Id,
                        Name = attachmentType.Name
                    }).ToList();

另外,请知道Linq to Sql比Linq快14倍。。。

解决并发冲突

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