现在,.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引入关系数据

其他回答

解决并发冲突

同质数据源: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-如果您计划编辑一对一的表示层中数据的关系。意思是你不要计划在任何一个视图中组合来自多个表的数据或第页。实体框架-如果您计划在视图或页面中组合来自多个表的数据。制作更清楚的是,上述术语是特定于在视图或页面中操纵,而不仅仅是显示。这是重要的是要理解。使用实体框架,您可以将表格数据“合并”在一起以可编辑的形式呈现给演示层,然后提交表格后,EF将知道如何更新所有数据从各种表格中选择。可能有更准确的理由选择EF而不是L2S,但是这可能是最容易理解的。L2S没有能够合并数据以进行视图显示。

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

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

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倍。。。

LINQ to SQL Entity Framework
It only works with SQL Server database It can work with various databases like Oracle, DB2, MySQL, SQL Server, etc.
It generates .dbml to maintain the relation It generates a .edmx file initially. The relation is maintained using 3 different files; .csdl, .msl and .ssdl
It has not to support for complex types It has support for complex types
It cannot generate database from model It can generate database from model
It allows only one-to-one mapping between the entity classes and the relational tables/views It allows one-to-one, one-to-many, many-to-many mappings between the entity classes and relational tables/views
It allows you to query data using DataContext It allows you to query data using EntitySQL, ObjectContext, DbContext
It can be used for rapid application development only with SQL Server It can be used for rapid application development with RDBMS like SQL Server, Oracle, PostgreSQL, etc.

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

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