现在,.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不能单独做什么?
当前回答
这里的答案涵盖了Linq2Sql和EF之间的许多差异,但有一个关键点没有得到太多关注:Linq2Sql只支持SQL Server,而EF为以下RDBMS提供了提供程序:
由Microsoft提供:
用于SQL Server、OBDC和OLE DB的ADO.NET驱动程序
通过第三方提供商:
MySQL数据库神谕分布式数据库维斯塔数据库数据库PostgreSQLInformix公司U2型Sybase公司Synergex公司火鸟Npgsql语言
举几个例子。
这使得EF成为关系数据存储的强大编程抽象,这意味着无论底层数据存储如何,开发人员都可以使用一致的编程模型。这在开发产品时非常有用,您希望确保产品能够与广泛的通用RDBMS互操作。
这种抽象有用的另一种情况是,您是一个开发团队的一部分,该团队与许多不同的客户或组织内的不同业务部门合作,您希望通过减少他们必须熟悉的RDBMS的数量来提高开发人员的生产力,以便在不同的RDBMS之上支持一系列不同的应用程序。
其他回答
这里有一些指标。。。(量化事物!!!)
我在使用实体框架的地方进行了这个查询
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倍。。。
我认为,如果您需要快速开发一些东西,而中间没有奇怪的东西,那么您需要有代表您的表的实体:
Linq2Sql可以是一个很好的联盟,将它与LinQ一起使用可以释放出一个良好的开发时机。
我的印象是,如果Linq2Sql不符合您的需求,那么您的数据库就相当糟糕或者设计得非常糟糕。我有大约10个大大小小的网站都在使用Linq2Sql。我已经多次查看和实体框架,但我找不到在Linq2Sql上使用它的好理由。也就是说,我尝试使用我的数据库作为模型,所以我已经在模型和数据库之间建立了1对1的映射。
在我目前的工作中,我们有一个拥有200多个表的数据库。一个有很多糟糕解决方案的旧数据库,因此我可以看到实体框架优于Linq2Sql的好处,但我还是希望重新设计数据库,因为数据库是应用程序的引擎,如果数据库设计糟糕且速度慢,那么我的应用程序也会很慢。在这样的数据库上使用Entity框架似乎是一种快速修复方法,可以掩盖坏模型,但它永远无法掩盖从这样的数据库中获得的糟糕性能。
我正在为一个使用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)更具未来性。
这里的答案涵盖了Linq2Sql和EF之间的许多差异,但有一个关键点没有得到太多关注:Linq2Sql只支持SQL Server,而EF为以下RDBMS提供了提供程序:
由Microsoft提供:
用于SQL Server、OBDC和OLE DB的ADO.NET驱动程序
通过第三方提供商:
MySQL数据库神谕分布式数据库维斯塔数据库数据库PostgreSQLInformix公司U2型Sybase公司Synergex公司火鸟Npgsql语言
举几个例子。
这使得EF成为关系数据存储的强大编程抽象,这意味着无论底层数据存储如何,开发人员都可以使用一致的编程模型。这在开发产品时非常有用,您希望确保产品能够与广泛的通用RDBMS互操作。
这种抽象有用的另一种情况是,您是一个开发团队的一部分,该团队与许多不同的客户或组织内的不同业务部门合作,您希望通过减少他们必须熟悉的RDBMS的数量来提高开发人员的生产力,以便在不同的RDBMS之上支持一系列不同的应用程序。