LINQ TO SQL和Entity Framework 的关系 你了解多少？

1. LINQ  TO SQL 和EF 特点：  LINQ TO SQL和Entity Framework都是一种包含LINQ功能的ORM 也就是所谓的关系对象的映射。其中包括的有DBFrist  Code Frist    ModeL  Frist   三种中方式 来进行和数据库之间的访问。只是形式不同而已本质没有什么区别。都是ORM  之间的转化。最终都是来进行访问底层的数据库的对象 和服务。

简单来说LINQ是为了满足不知道怎么操作数据库的程序员开发设计的，LinQ 可以让他们以一种面向数据对象的方式来思考，及持久化他们的数据。 当然最后来进行访问数据库的无论是Oracle SQL Server  MySQL   MongoDB   DB2  等等 都是最终生成 SQL 语句来进行访问数据库的 和传统的ADO.NET 直接来访问数据库没有什么直接的区别，只是,MicroSoft  将其 CRUD 的一些方法进行封装了而已，让开发使用起来更加的方便  开发的速度更加的快速 ，更加的专注于核心的业务的开发的开发 ，而不是在为这些简单的操作而耽搁太多的时间。可以让开发节省更多的开发的时间 去做更多的事情。

当然你使用SQL Server  中的SQL Profile  来进行 查看 其中生成的SQL , 那么问题来了 如果Oracle  MySQL  DB2   MongoDB   如何进行查看生成的SQL 语句 了。那么这个时候你需要进行 使用nuGet 来进行添加一个第三方的程序集。MiniProfiler.dll 来进行查看生成的生成的SQL 语句  当然关于如何使用 可以进行参考 （http://www.cnblogs.com/jiekzou/p/6374726.html） 博客上面具有介绍我就不一一的说了。其中 无论是LINQ TO SQL  还是 EF 最终的形式 都是通过DBContent  来进行访问数据库。

LINQ  TO  SQL 和Entity Framework 两者的本质的区别：

EF对数据库架构和我们查询的中实现更好的解耦。使用EF，我们查询的对象不再是完全对应数据库架构的C#类，而是更高层的抽象：Entity Data Model。这为我们提供了额外的灵活性其中在性能和简单性上面也会有所损失。 这个是必须的。 毕竟在解析中性能以及功能性都是有所损失的。

优点：LINQ TO SQL，是一个轻量级的ORM框架，为Microsoft SQL Server数据库提供快速的应用程序开发，其优点是易于使用、简单、高性能。Entity Framework，为创建数据库架构和实体类之间的映射提供了更好的灵活性，它还通过提供程序支持除了SQL Server之外的第三方数据库。 例如其中的MySQL  Oracle  MongoDB  DB 2  等等 都是可以映射以及访问的。

EF  6.0 经过Microsoft 的改进性能相对于EF 4.0 确实提升了不少 其中对于CRUD 的访问。这意味着我们在系列文章中的LINQ  TO  DB 查询可以同时适用于EF 4.0 以下的版本和L2S。而且，这也使得LINQ TO SQL  成为我们学习使用LINQ查询数据库的理想技术， 因为保持着对象和关系之间的映射的性 那么 在使用变得的非常的简单 以及灵活性，并且我们学习到的查询原则和技术同样适用于EF。

说明：.NET 3.5下建议使用LINQ TO SQL ，该版本已经完全支持成熟的LINQ；使用EF则建议使用.NET 4.0+（VS2010）以上的版本，该版本有成熟完整的EF

2.LINQ  TO  SQL 和Entity Framework 复杂度：

LINQ  TO  SQL 支持特性比较少一些；但是相对于EntityFramework支持的特性比较多，所以稍微比较复杂一些但是 两者可以相互结合的使用。将其转化集合 还是非常好使用的。没必要将形式局限与  LINQ TO  SQL  还是其中的LAMBDA 表达式上卖弄

LINQ TO SQL在数据表与类之间提供了一对一的映射 和一对多之间的关系等等 当然 你也可以进行对于将对象直接作为查询的条件进行 查询这样的效率是非常的高的。

LINQ  TO SQL只支持Microsoft SQL Server 2000及之后的版本当然你选择的数据库版本高一些还是比较好的 毕竟高版本的数据库使用起来无论是性能还是操作起来都是非常的方便的，但即使是SQLServer2000也有很多限制。EntityFramework可以支持DB2, MonogoDB, Oracle, MySQL还有其他的数据库等等。

3.LINQ  TO  SQL 和Entity Framework开发时间：

LINQ TO  SQL很容易学，开发起来也很快，但是LINQ TO SQL有一些限制，在开发较复杂的应用时可能会产生问题。EntityFramework的能力更强，虽然学习及应用起来比较慢，但是对更多的特性的支持使得在开发较复杂的应用时可以使问题最小化。当然我建议一些初学者还是老老实实的 从ADO.NET 开始进行学起 ，毕竟 知道知其然然后知其所以然 这样对于你写的Linq TO  SQL  还是 EF 都是帮助非常的大的。

4.LINQ  TO  SQL 和Entity Framework继承：

LINQ TO SQL支持TPH，而EntityFramework支持TPH和TPT，并且对TPC也部分支持。

5.LINQ  TO  SQL 和Entity Framework 文件类型：

LINQ to SQL使用包含XML的数据库标记语言(DBML)文件来映射entity与数据表。EntityFramework 使用四个文件。第一个是Entity Data Model (EDMX)，这个是在设计器中使用的。在编译时EDMX文件产生了其他三个文件。另外三个文件中，第一个是ConceptualSchema Definition Language(CSDL)文件，其包含概念模型的XML定义。第二个是SchemaDefinition Language(SSDL)文件，其包含存储模型的定义。第三个文件是Mapping Specification Language(MSL)文件，其包含概念模型与存储模型之间的映射。

6.LINQ  TO  SQL 和Entity Framework 复杂类型的变化：

比如说，我们遇到一些复杂的表格进行关联的时候。LINQ  TO  SQL不支持这种复杂类型，而EntityFramework支持。但是我们遇到这样的问题的时候可以通过将EF 结合到 LINQ TO  SQL  集合来进行查询 并进行 处理就可以了。

 1 //例如下面进行查询过和订单相互关联的数据集合
 2
 3  var AccountList = (from u in StarList.Where(u => u.FUST_LEVEL == 3).ToList()
 4
 5  join p in MyDataContexter.fa_brokerage_bill_table.Where(p => p.FBBT_TIME.Year == date.Year && p.FBBT_TIME.Month == date.Month && p.FBBT_STATE != 0).ToList() on u.FUST_ID equals p.FBBT_FUST_ID
 6
 7 orderby p.FBBT_CREATETIME descending
 8 select new AccountInfo
 9 {
10 Flag = u.FUST_LEVEL,
11 UserImg = AliyunRoot+u.FUST_HEADIMAGE,
12 UserName = u.FUST_REALNAME != "" ?( u.FUST_REALNAME.Length > 3 ? u.FUST_NICKNAME.Substring(0, 3) + "..." : u.FUST_NICKNAME) : (u.FUST_NICKNAME.Length > 3 ? u.FUST_NICKNAME.Substring(0, 3) + "..." : u.FUST_NICKNAME),
13 Income = p.FBBT_BIGSTAR_MONEY.ToString("N2") ?? "0.00",
14 ShowIncome = p.FBBT_BIGSTAR_MONEY,
15 StarID = u.FUST_ID,
16 StarLevel = u.FUST_LEVEL,
17 JoinTime = u.FUST_JOINTIME.ToString("yyyy-MM-dd")
18 }).ToList();

7.LINQ  TO  SQL 和Entity Framework 查询的速度和能力：

LINQ TO SQL通过DataContext对数据库进行查询。EntityFramework通过ObjectContext通过LINQ TO  ENTITY 进行查询。Entity Framework还提供了EDMX SQL，它是一种类似SQL的查询语言，很适合在模型定义中定义查询。EntityFramework还包含了 ObjectQuery类，用于对象服务在运行时动态创建查询。最后EntityFramework还包含EntityClientProvider，它 用于对概念模型进行查询。

 1 // 查询销售记录
 2 var QWXery = (from s in XZUser.Where(e => e.FUST_LEVEL == 2)
 3 where s.FUST_LEVEL_ID == strUserID
 4 join a in MyDataContexter.fa_brokerage_sales_table on s.FUST_ID equals a.FBPT_FUST_ID
 5 group a by a.FBPT_FUST_ID into g
 6 select new
 7 {
 8 g.Key,
 9 ZCount = g.Count(),
10 ZMoney = g.Sum(p => p.FBPT_MONEY)
11 }).ToList();
12 // 查询订单记录
13 var QXXery = (from s in XZUser.Where(e => e.FUST_LEVEL == 3)
14 where s.FUST_RECOMMEND_ID == strUserID
15 join b in MyDataContexter.fa_brokerage_sales_table
16 on s.FUST_ID equals b.FBPT_BUY_FUST_ID
17 group b by b.FBPT_BUY_FUST_ID into g
18 select new
19 {
20 g.Key,
21 ZCount = g.Count(),
22 ZMoney = g.Sum(p => p.FBPT_MONEY)
23 }).ToList();
24 // 联合一下
25 var QuerList = (from z in (from s in QWXery select s).Union(
26 from a in QXXery select a)
27 select new OrderList
28 {
29 ID = z.Key,
30 GCount = z.ZCount,
31 HJMoney = z.ZMoney
32 }).ToList();
33 return QuerList;
34 }
35 else
36 {
37 // 查询星星就可以了
38 var QXXery = (from s in XZUser
39 where s.FUST_RECOMMEND_ID == strUserID
40 join b in MyDataContexter.fa_brokerage_sales_table
41 on s.FUST_ID equals b.FBPT_BUY_FUST_ID
42 group b by b.FBPT_BUY_FUST_ID into g
43 select new OrderList
44 {
45 ID = g.Key,
46 GCount = g.Count(),
47 HJMoney = g.Sum(p => p.FBPT_MONEY)
48 }).ToList();
49
50 return QXXery;
51 }

8.LINQ  TO  SQL 和Entity Framework  性能：

LINQ  TO  SQL和Entity Framework 在第一次进行比较缓慢 这个由于进行访问 数据从而 在解析以及读取数据等等 速度并不让人满意，但是只有在进行请求 访问的时候速度就比较快了 因为LINQ TO SQL  和EF  都涉及到一个延迟加载的问题 第二次加载后由于读取的数据早已放入 缓存 中 速度还是让人满意的 所以开发以及用户200W 以内的数据的数据 就没有必要去考虑这些性能的问题， 毕竟EF 6.0对于EntityFramework 做了很大的优化性能要稍微优于LINQ TO  SQL。 还是非常值得使用的。  如果对于并发可以考虑采用事务或者LOCK 来进行处理这些问题。 如果真是数据量非常的大那么查询过的结构足够的复杂，那么 采用存储过程 来做倒是还不错的。LINQ TO SQL  存储过程  EF  存储过程 来做 。倒是挺好的。

9.LINQ  TO  SQL 和Entity Framework  优化的处理：

一直有人对于 EF 和   LINQ  TO  SQL  的性能的问题存在很大的质疑 当然 这个是必须的。对于我们写的 LINQ  语句 以及 LAMBDA  的时候需要注意 就是了 理清楚表之间的关系 以及各个对象之间的关系，做到优化的查询 等等。具体如果做 我抽时间在写关于如何优化LINQ   表达式以及 LAMBDA  表达式做法。

                                                                                 以上内容 全部属于原创！ 部分观点 引用 了维基百科 和其他博客观点 已经声明！    2017/7/5  00:23：35