参考页面:
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:非也。然后后续的步骤更加不知所云。下面说说我是怎么处理的:
- 简单起见,设有一张库存表,表结构:,木有主键,now,从数据库生成Model;
- 用记事本打开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>
这一步骤也可以直接在关系图中设置
- 继续在记事本中查找<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就是表明对应实体为只读。
- 在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中重用现有的数据库连接字符串
转载请注明本文出处:http://www.cnblogs.com/newton/archive/2013/05/27/3100927.html