现在,.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不能单独做什么?
当前回答
这里有一些指标。。。(量化事物!!!)
我在使用实体框架的地方进行了这个查询
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倍。。。
其他回答
我在实体框架方面的经验并不出色。首先,您必须从EF基类继承,所以向POCO说再见。你的设计必须围绕EF。使用LinqtoSQL,我可以使用现有的业务对象。此外,没有延迟加载,您必须自己实现。有一些变通方法可以使用POCO和延迟加载,但它们存在IMHO,因为EF还没有准备好。我计划在4.0后重新开始
解决并发冲突
同质数据源: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-如果您计划编辑一对一的表示层中数据的关系。意思是你不要计划在任何一个视图中组合来自多个表的数据或第页。实体框架-如果您计划在视图或页面中组合来自多个表的数据。制作更清楚的是,上述术语是特定于在视图或页面中操纵,而不仅仅是显示。这是重要的是要理解。使用实体框架,您可以将表格数据“合并”在一起以可编辑的形式呈现给演示层,然后提交表格后,EF将知道如何更新所有数据从各种表格中选择。可能有更准确的理由选择EF而不是L2S,但是这可能是最容易理解的。L2S没有能够合并数据以进行视图显示。
在@lars发布的文章中,有许多明显的区别,但简短的回答是:
L2S是紧密耦合的-对象属性到数据库的特定字段,或者更正确地将对象映射到特定数据库模式L2S仅适用于SQL Server(据我所知)EF允许将单个类映射到多个表EF将处理M-M关系EF将能够针对任何ADO.NET数据提供程序
最初的前提是L2S用于快速开发,EF用于更多的“企业级”n层应用程序,但这使L2S的销售有点不足。