Entity Framework初探

参考页面:

http://www.yuanjiaocheng.net/entity/change-tracking.html

http://www.yuanjiaocheng.net/entity/Persistence-in-EF.html

http://www.yuanjiaocheng.net/entity/crud-in-connected.html

http://www.yuanjiaocheng.net/entity/crud-in-Disconnected.html

http://www.yuanjiaocheng.net/entity/add-entity-in-disconnected.html

近期公司打算使用EF,于是这两天我特地研究了它的一些特性。本文记录的是我的一些研究成果。。。哎哟,说成果是不是大了点?

ps:对于EF,每次它有新版发布,我都一笑而过,为啥?因为我一直非常安逸于使用一个叫IQToolkit的开源组件,该组件作者有专门写了一系列博文记录IQToolkit从无到有的诞生历程,我估计市面上很多基于Linq的ORM或多或少都借鉴过他的经验[和代码]。我从中也受益良多,虽然偶有不足,但大部分略作改造即可弥补。它和EF相比,恰如穷屌丝和高富帅,下面有几个地方我会拿它们作一对比。

1、原有项目引入EF



EF有个DB First模式,可以根据数据库自动生成POCO实体和映射关系,生成的实体是与数据表一一对应,各自独立的。若原有项目已存在实体类库,由于一些原因想保留之,比如各实体可能共享一些基类或接口,以便在业务层针对基类抽取共同逻辑,这些继承关系不想抛弃。我们可以这么做,当新建edmx文件后,删除所有自动生成的POCO,包括xxx.tt模板文件一同删除,否则当修改edmx时,系统会根据模板重新生成POCO。删完之后将xxx.Context.cs文件中的实体引用改为原项目实体。我们还可以修改xxx.Context.tt模板文件,使之生成的相应DbContext类(在xxx.Context.cs中)符合我们的要求。

2、EF是主键控



EF的上下文特性需要能唯一标识实体的方法,这无可厚非,然而EF非常固执地只认主键,当数据表没有主键时,对应的实体就不能Update和Delete,这是一个非常严重的“Bug”。很多人会问:“难道表不应该有主键吗?”不幸的是,这种情况很普遍。主键存在的意义是标示数据表中的某一条记录,以便于我们能通过它去精确定位[、更新和删除]数据。但很多时候我们并不会独独去get某一条记录。比如发货单,分为主表和子表,对子表的都是整单查询操作,或者数据汇总,或者根据业务字段作为索引去查,因此并不会为子表的记录新增一个毫无意义的主键。另一种考虑是,由于主键对Insert操作的效率影响,常用非聚集索引代替,以尽量减少全表排序。

当我们试图Delete没有主键的表数据时:

所幸,微软似乎意识到这个问题,于是默默地写了一篇How to: Create an Entity Key When No Key Is Inferred。不过这篇文章里的内容虽然号称是最新版本,但是跟我实际所得有很大出入,文中说没有主键的数据表是不会产生Model的(原话:If no entity key is inferred, the entity will not be added to the model.文中所述还是正确的,意思为如果数据库中没有主键且EF不能自动定义出主键(默认是所有字段为一个组合主键),如有字段为null的情况,而非我之前认为的单单数据库没有主键;另外EF自动定义的主键所在的表默认是只读的),I say:非也。然后后续的步骤更加不知所云。下面说说我是怎么处理的:

  1. 简单起见,设有一张库存表,表结构:,木有主键,now,从数据库生成Model;
  2. 用记事本打开edmx文件,我们会找到两处同样的片段:

     1 <EntityType Name="Stock">
     2   <Key>
     3     <PropertyRef Name="StorageID" />
     4     <PropertyRef Name="ProductID" />
     5     <PropertyRef Name="Quantity" />
     6   </Key>
     7   <Property Name="StorageID" Type="int" Nullable="false" />
     8   <Property Name="ProductID" Type="int" Nullable="false" />
     9   <Property Name="Quantity" Type="int" Nullable="false" />
    10 </EntityType>

    一个是在SSDL节点下,一个是CSDL节点(就刚才的文说在SSDL中是注释掉的,其实没有;说CSDL中没有,其实有的),由于没有主键,框架自作聪明地将所有字段都列为复合主键,而且该片段对应的实体是只读的……由于StorageID和ProductID已经组成了一个非聚集唯一索引(这么做的原因前已表述),对于UD操作来说等同于主键,因此删除<PropertyRef Name="Quantity" />片段变为:

    1 <EntityType Name="Stock">
    2   <Key>
    3     <PropertyRef Name="StorageID" />
    4     <PropertyRef Name="ProductID" />
    5   </Key>
    6   <Property Name="StorageID" Type="int" Nullable="false" />
    7   <Property Name="ProductID" Type="int" Nullable="false" />
    8   <Property Name="Quantity" Type="int" Nullable="false" />
    9 </EntityType>

    这一步骤也可以直接在关系图中设置

  3. 继续在记事本中查找<EntitySet Name="Stock" EntityType="DistributionModel.Store.Stock" store:Type="Tables" store:Schema="dbo" store:Name="Stock">......</EntitySet>这一段,改为<EntitySet Name="Stock" EntityType="DistributionModel.Store.Stock" store:Type="Tables" Schema="dbo" />,目测store:XXX就是表明对应实体为只读。
  4. 在Stock实体属性StorageID和ProductID加上特性[Key]。完毕。

ps:EF并不负责维护使用该方式设置的“主键”的唯一性,这仍然需要我们在业务层面控制。

 3、什么!?EF的字典里没有“批量”的概念?



上述方法“完美地”解决了主键问题,我们来试试看:

 1 [TestMethod]
 2 public void TestMethod6()
 3 {
 4     using (var entities = new DistributionEntities())
 5     {
 6         var test = entities.Stock.Where(o => o.Quantity == 0).ToList();
 7         foreach (var t in test)
 8             entities.Stock.Remove(t);
 9         entities.SaveChanges();
10     }
11 }

不出所料,执行成功,不过我要说的并不是这个,而是这种删除模式——先从数据库里取出要删的数据,然后代码层跟上下文说我要将这些数据从表里删除,上下文再去执行最后的步骤——是不是很坑爹?我相信您肯定有蛋疼的感觉(这里假定你是男人),and,(人生最害怕的就是这个and!)如果您去到数据库里走一遍跟踪,想看看entities.SaveChanges()做了什么事,您的蛋基本上就碎了。

没错,EF的上下文特性的前提是所有对数据的更改都要通过主键定位完成,这也就是第2条描述的内容。so,它会针对每个已编辑或已删除实体单独生成一条语句。如果一次操作有上万个实体需要更新,效率会否有影响?

不管怎样,有人按捺不住,写了一个扩展组件EntityFramework.Extended,可以通过NuGet获取,可参看Entity Framework Batch Update and Future Queries。现在我们可以这样:

1 [TestMethod]
2 public void TestMethod4()
3 {
4     using (var entities = new DistributionEntities())
5     {
6         entities.Stock.Delete(o => o.Quantity == 0);
7     }
8 }

避免了往返数据库两次的尴尬,同时只生成了一条语句:

DELETE [dbo].[Stock]
FROM [dbo].[Stock] AS j0 INNER JOIN (
SELECT
[Extent1].[StorageID] AS [StorageID],
[Extent1].[ProductID] AS [ProductID],
[Extent1].[Quantity] AS [Quantity]
FROM (SELECT
      [Stock].[StorageID] AS [StorageID],
      [Stock].[ProductID] AS [ProductID],
      [Stock].[Quantity] AS [Quantity]
      FROM [dbo].[Stock] AS [Stock]) AS [Extent1]
WHERE 0 = [Extent1].[Quantity]
) AS j1 ON (j0.[StorageID] = j1.[StorageID] AND j0.[ProductID] = j1.[ProductID] AND j0.[Quantity] = j1.[Quantity])

似乎跟预想的有点不太一样,印象中,偶觉得,可能,大概,或许,Maybe不应该是这么长一段吧……在代码的世界中,追求的是短小精悍!于是我招呼屌丝IQToolkit给观众展示一下:

1 [TestMethod]
2 public void TestMethod5()
3 {
4     QueryGlobal distrContext = new QueryGlobal("DistributionConstr");
5     distrContext.LinqOP.Delete<Stock>(o => o.Quantity == 0);
6 }

这里的distrContext可以理解为上下文,关于这点后面说。LinqOP是我封装IQToolkit的通用操作,最终数据库跟踪到这么一条:

DELETE FROM [Stock]
WHERE ([Quantity] = 0)

所以说,屌丝总有逆袭时!由于只对必要字段做比较,肯定比EntityFramework.Extended生成的语句执行效率高。如果真用上EF,我得改进这方面的SQL构造算法,要是哪位朋友已经做了相关工作,请务必提供出来造福猿类社会……

ps:关于通过主键定位数据然后删除 or 判断Quantity是否为0,若是则删除,两者效率对比情况如何我没做深入研究,估计具体情况具体分析,有经验的朋友可以说说看

4、所谓上下文



EF的上下文有两个概念:DbContext和ObjectContext,它们有一定区别,能相互转换,具体可看Data Points,这里一般指DbContext。我认为,上下文的主要作用就是跟踪实体状态,这样注定了会生成如第3条那样的数量巨大的SQL语句,也就难怪没有批量更新的原生方法。由于上下文在SaveChanges时提交所有已更改的数据,所以我们也不能将之设为单例模式,只能在每次用到的时候,不厌其烦地using。优点是使得SaveChanges能让多个操作集中在一次数据库连接会话内完成。but,很多时候我们并不需要跟踪实体状态,也不需要更新数据,比如报表系统。我喜欢将一些通用操作抽取出来,比如我封装IQToolkit的几个方法:

 1 /// <summary>
 2 /// 查询符合条件的集合
 3 /// </summary>
 4 /// <typeparam name="T">类型参数</typeparam>
 5 /// <param name="condition">查询条件</param>
 6 /// <param name="order">排序规则,目前只支持单属性升序排序</param>
 7 /// <param name="skip">从第几条数据开始</param>
 8 /// <param name="take">取几条数据</param>
 9 /// <returns>符合条件的对象集合</returns>
10 public IQueryable<T> Search<T>(Expression<Func<T, bool>> condition = null, Expression<Func<T, dynamic>> order = null, int skip = 0, int take = int.MaxValue)
11 {
12     return Search(t => t, condition, order, skip, take);
13 }
14
15 public IQueryable<R> Search<T, R>(Expression<Func<T, R>> selector, Expression<Func<T, bool>> condition = null, Expression<Func<T, dynamic>> order = null, int skip = 0, int take = int.MaxValue)
16 {
17     var entities = this._provider.GetTable<T>(typeof(T).Name);
18     if (selector == null)
19         throw new ArgumentNullException("selector", "涉及类型转换的构造委托不能为空");
20     if (condition == null)
21         condition = t => true;
22     IQueryable<T> query = entities.Where(condition);
23     if (order != null)
24         query = query.OrderBy(order).Skip(skip).Take(take);
25     return query.Select(selector);
26 }

注意它返回的是IQueryable<T>,因此能在外部多次调用,并任意组装,一定程度上更灵活。this._provider.GetTable<T>(typeof(T).Name),要去哪个表里取数,它并没有上下文的概念。用EF则不能如此封装,IQueryable<T>只在上下文中才有效,你想在上下文using块返回后再去使用IQueryable<T>会报异常,如下面示例代码:

那么我们不using行不行?using的作用是保证上下文呢能Dispose掉,上下文Dispose的作用是取消各实体对象由于保存状态指向上下文自身的引用,以及上下文指向它们的引用,这样不论是实体对象还是上下文占用内存都能被GC回收(Dispose并不是我们下意识认为是关闭数据库连接,数据库连接在任意生成的SQL执行完就自动关闭)。也许我可以尝试使用Data Points文中提到的AsNoTracking特性,单独列几个Context作为全局上下文,不用using,因为本身不跟踪实体状态,所以不会导致内存溢出,可以一直存在。注意AsNoTracking并不表示返回的IQueryable能独立于上下文存在,毕竟还需要上下文去构造SQL语句之类的工作。

ps:截图例子中,若将两个SearchXXX方法内的using去掉,会出现什么情况呢?

其余代码相同。看到,即使是同样类型的两个不同上下文实例,也不能放一起关联查询。

5、其它


  • IQToolkit执行无误,EF报错:

  • 引用EF后,需要using System.Data.Entity;否则木有智能提示!
  • 当已存在实体类库和数据库,要引入EF,需要注意实体类要显式定义与数据表的列名对应的所有属性(计算列未知是否一定要定义相应属性);而IQToolkit的实体类可以缺省某些类型的列(如该列自动填充默认值)。当数据表中的列没有在类型中找到对应属性,会报“the entity type is not part of the model for the current context”(中文为:实体类型不是当前上下文的模型的一部分)的异常,让人摸不着头脑。我曾为此折腾了足足两天,最后才发现是因为少了一个字段!ps:不过EF中的实体可以定义数据表中不存在的额外字段,而不会报错。
  • 在查询条件中设置如o.CreateTime <= time.AddDays(1).Date条件,EF会报“Linq to Entities不识别方法DateTime.AddDays(double),该方法无法转为存储过程”的错误,IQToolkit表示无压力。这是因为EF默认在Query内部不支持正常方式调用CLR方法,而是提供了EntityFunctions,其中内置了部分常用方法,还提供了自定义方法的方式,在运行时这些方法会转换为对应的sql语句(估计自定义方法的方法体可以不用实现,因为它起到的是映射作用)。
  • dbContext.Database.SqlQuery返回结果上下文不跟踪,默认情况下,dbContext.DbSet.SqlQuery返回的是上下文跟踪实体。

更多参考:

在Entity Framework中重用现有的数据库连接字符串

Entity Framework之深入分析

Add/Attach and Entity States

EF中使用SQL语句或存储过程

转载请注明本文出处:http://www.cnblogs.com/newton/archive/2013/05/27/3100927.html

时间: 2024-09-29 05:34:59

Entity Framework初探的相关文章

Entity Framework的查询

Entity Framework是个好东西,虽然没有Hibernate功能强大,但使用更简便.今天整理一下常见SQL如何用EF来表达,Func形式和Linq形式都会列出来(本人更喜欢Func形式). 1.简单查询: SQL: SELECT * FROM [Clients] WHERE Type=1 AND Deleted=0 ORDER BY ID EF: //Func形式 var clients = ctx.Clients.Where(c => c.Type == 1 && c.D

Entity Framework 6 Recipes 2nd Edition(9-3)译-&gt;找出Web API中发生了什么变化

9-3. 找出Web API中发生了什么变化 问题 想通过基于REST的Web API服务对数据库进行插入,删除和修改对象图,而不必为每个实体类编写单独的更新方法. 此外, 用EF6的Code Frist实现数据访问管理. 本例,我们模拟一个N层场景,用单独的客户端(控制台应用)来调用单独的基于REST服务的Web网站(WEB API应用) . 注意:每层使用单独的Visual Studio 解决方案, 这样更方便配置.调试和模拟一个N层应用. 假设有一个如Figure 9-3所示的旅行社和预订

Entity Framework 学习

Entity Framework 学习初级篇1--EF基本概况... 2 Entity Framework 学习初级篇2--ObjectContext.ObjectQuery.ObjectStateEntry.ObjectStateManager类的介绍... 7 Entity Framework 学习初级篇3-- LINQ TOEntities. 10 Entity Framework 学习初级篇4--EntitySQL. 17 Entity Framework 学习初级篇5--ObjectQ

异常:error 0152: No Entity Framework provider found for the ADO.NET provider with invariant name &#39;System.Data.SqlClient&#39;

error 0152: No Entity Framework provider found for the ADO.NET provider with invariant name 'System.Data.SqlClient' error 0152: No Entity Framework provider found for the ADO.NET provider with invariant name 'System.Data.SqlClient'. Make sure the pro

初次开发 ASP.NET vNext 续篇:云优化的概念、Entity Framework 7.0、目前性能还不够好

继续上一篇<开发 ASP.NET vNext 初步总结(使用Visual Studio 2014 CTP1)>之后, 关于云优化和版本控制: 我本想做一下MAC和LINUX的self-host测试,但是官方说运行环境的MONO版本至少需要3.4.1,我去年买了个表,至本文发布为止,你让我下地狱去找3.4.1吗,硬着头皮用3.4.0搞了一晚上,MAC一直停留在 httpapi.dll出错,Ubuntu Server 12.0.4 是不认其中的几个DLL包,具体哪几个也忘了,过段时间有了稳定版本再

Entity Framework Code First for SQL Compact

这篇博客将介绍EF Code First中如何使用SQL Compact.SQL Compact是微软推出的免费的关系型数据库,目前最新版本是SQL Compact 4.0.微软的开发工具VS 2010/SQL Server 2008及后续版本中均不带有SQL Compac 3.5/4.0t数据库查看工具.不过CodePlex上有一个SqlCeToolbox的工具非常不错.有点儿像精简版的SQL Server Management Studio. SQL Compact可以用于以下的一些场景,例

Linux + Mono 目前已经支持Entity Framework 6.1

在上个随笔 CentOS上 Mono3.2.8运行ASP.NET MVC4经验中,步骤2中要求卸载EF 5.0,这样才能在Linux + Mono的环境中运行ASP.NET MVC4的Web应用.今天,没有卸载EF 5.0的情况下,使用NuGet新安装了EF 6.1.0,如下图(使用VS012英文版), 图1: 新安装了Entity Framework 6.1.0,同时EF5.0没有卸载,可在图片中看到两个EF共存 图1中的这个网站是一个接近完成的完整网站,在其它各项配置都与 CentOS上 M

Entity Framework工具POCO Code First Generator的使用

在使用Entity Framework过程中,有时需要借助工具生成Code First的代码,而Entity Framework Reverse POCO Code First Generator是一款不错的工具 在Visual Studio中,通过"工具"→"扩展和更新..."来安装Entity Framework Reverse POCO Code First Generator 这里添加一个控制台项目,并在项目中添加POCO Code First Genera

Entity Framework 6 和 MVC5

网站地址: Entity  Framework 6   http://msdn.microsoft.com/en-us/data/ef.aspx MVC5     http://www.asp.net/mvc