随笔分类 - 其它 / Entity Framework
微软即linq to sql之后又一个成功的ORM软件，它可以生成三种ORM方式，如数据优先，代码优先和模型优先
摘要：回到目录第一讲 认识IUnitOfWork，为什么要出现IUnitOfWork接口第二讲 Linq to Sql与EntityFrameworks中的SubmtChanges()发生了什么事第三讲 方法完整性与统一提交不冲突第四讲 DbContext对象的创建应该向BLL层公开第五讲 我的IUnitOfWork+Repository架构这个系统的文章在写完这篇后将拉下眉目，一共5讲的IUnitOfWork带给我们的是性能，原子化操作，等多方法的改进，下面我把我的IUnitOfWork+Repository模式大体的说一下，并代上核心代码：底层接口UnitOfWork.Data.Core这是一个
阅读全文
摘要：回到目录第一讲 认识IUnitOfWork，为什么要出现IUnitOfWork接口第二讲 Linq to Sql与EntityFrameworks中的SubmtChanges()发生了什么事第三讲 方法完整性与统一提交不冲突第四讲 DbContext对象的创建应该向BLL层公开第五讲 我的IUnitOfWork+Repository架构在EF中，数据上下文通常是DbContext或者ObjectContext，而在linq to sql中数据上下文则是DataContext，它们的作用是建立一个数据库映射对象ORM，以更加方便的操作数据库，而它们的创建工作，我在很长一段时间将它约束在DAL层，
阅读全文
摘要：回到目录第一讲 认识IUnitOfWork，为什么要出现IUnitOfWork接口第二讲 Linq to Sql与EntityFrameworks中的SubmtChanges()发生了什么事第三讲 方法完整性与统一提交不冲突第四讲 DbContext对象的创建应该向BLL层公开第五讲 我的IUnitOfWork+Repository架构 在一个方法中，它一般会做一件事情，这样的方法在功能上比较清晰，在职责上也很单一（这里的单一是褒义的，呵呵），而它所做的这件事，从头到尾会把它做完，不会做到一半的功能，这属于功能上的不完整，这不是我们推荐的。项目中的代码：完整的提交方法： prot...
阅读全文
摘要：回到目录第一讲 认识IUnitOfWork，为什么要出现IUnitOfWork接口第二讲 Linq to Sql与EntityFrameworks中的SubmtChanges()发生了什么事第三讲 方法完整性与统一提交不冲突第四讲 DbContext对象的创建应该向BLL层公开第五讲 我的IUnitOfWork+Repository架构 对于微软推出的linq to sql和entity frameworks这两大ORM工具，它为我们的程序开发推供的是操作简单，程序结构清晰，代码量少，但在性能上，往往是开发者议论的焦点的，确实，有时这些ORM工具的不可控与操作不透明性广泛被开发者所关注和注意。
阅读全文
摘要：回到目录第一讲 认识IUnitOfWork，为什么要出现IUnitOfWork接口第二讲 Linq to Sql与EntityFrameworks中的SubmtChanges()发生了什么事第三讲 方法完整性与统一提交不冲突第四讲 DbContext对象的创建应该向BLL层公开第五讲 我的IUnitOfWork+Repository架构 今天愉点时间，说说IUnitOfWork，它事实上是NHibernate上的东西，这里只是借一下它的思想，把咱们的EF和LinqToSql也优化一下，呵呵！对于IUnitOfWork它的中文是操作单元的意思，顾名思义，就是将多个操作放在一个单元中，把操作原子化
阅读全文
摘要：回到目录entity frameworks给我们代来的不只是操作方便，代码简洁，代码人性化强，而且更重要的是它的代码执行效率也是可以信任的，这一点对于我们来说十分重要，因为对于ORM来说，你再使用方便，再容易上手，如果你的性能低下，我估计也没人爱用，呵呵。今天主要说一下entity frameworks中的关联表插入问题，我们以订单业务为例来说一下：一 数据结果图如下：二 在EF中，数据结构关联图会体现在模型里，并且同时会生成在实体中，它以导航属性的形式出现，如图： public partial class Order_Info { public Order_Info(...
阅读全文
摘要：回到目录之前一起认为ＥＦ的延时加载存在性能问题，主要体现在一对多关系上，它会增加与数据库的通讯，而EF本身也提供了“立即加载”include，今天主要说一下它，经过实验，证明如下：最初接触EF延时加载时，以为只存在这种性能低下的方案，在了解include方法后，才知道这种神奇的方案，它与linq to sql中的DataLoadOptions比较类似，译为立即加载关联对象。在这里，我对include说一声，对不起，是我冤枉你了，呵呵。实验代码如下：Infrastructure层： public IQueryable<WebManageUsers> GetWebManageUsers
阅读全文
摘要：回到占占推荐博客索引 EF架构系列主是我在项目开发中，总结出现的一些经验性的东西，拿出来与大家分享，哪块与的有问题，还请大家指出来，然后我们一些再去讲究！ EF架构~系列目录 第一回 EF架构~了解一下,ADO.NET Entity Framework 第二回 EF架构~终于自己架构了一个相对完整的
阅读全文
摘要：回到目录我之前讲过为实体添加注释的文章，最近开发过程中，感觉有必要把Display特殊也做在T4模板里，这样，实现在前台绑定时，就把信息自动显示出来了，呵呵。主要分为两步：1 在T4模板里添加Display特性的命名空间 ， 2 在T4模板里为每个属性添加Display特性打开tt文件，后我们找到这行，添加命名空间然后再找到这行，为属性添加Display特性保存tt模板文件，这时，所有实体将会进行更新，打开实体文件后，你的特性就自己被加上了，在前台UI层进行绑定时，直接显示出名称来了，如果不是特别的业务可以不用再ViewModel了，呵呵！感谢您的阅读！回到目录
阅读全文
摘要：回到目录很多时间之长，我写了EF架构~性能高效的批量操作(Insert篇），而今天我把Update篇也写一下，这对于批量处理数据很有帮助，它解决了EF与linq to sql批量更新数据上的效率问题。对于EF架构中的批量更新操作，需要我们为实体的导航属性进行手动的标示，因为EF生成的实体中没有一个特殊的说明，所以，我们必须要告诉系统，哪个属性是导航属性，而导航属性是我们不去进行update的。1 /// <summary>2 /// 属性的导航属性3 /// </summary>4 public class NavigationAttribute : Attrib...
阅读全文
摘要：回到目录linq to entity或者linq to sql都提供了非常方便的延时加载功能，什么意思？就是说在建立对象时，它会将数据库中的表关系同时建立进来，然后在查询时，如果用到的外键表的数据，才会建立这个外键表的查询，这一点确实很“酷”，但是它是有代价的，甚至代价是巨大的。我一直不太喜欢我命运被别人去掌握着，写代码也一样，说着很好听的“延时加载”，用着也算方便，但对于它生成的ＳＱＬ代码却是让我很恐惧的，下面看一下截图：这是一个查出１０条结果的语句这只是一部分，它对于建立ＳＱＬ的connection是１０次，傻眼了吧，呵呵，这绝对是不能接受的，但如果你不用外键表，它是很正常的，一个ＳＱＬ链
阅读全文
摘要：回到目录相关文章系列第八回 EF架构~将数据库注释添加导入到模型实体类中第二十一回 EF架构~为EF DbContext生成的实体添加注释（T4模板应用）第二十二回 EF架构~为EF DbContext生成的实体添加注释（T5模板应用）使用EF架构时，你的实体生成方案有多种，entity object,poco,dbcontext等等，对于entity object方案生成的实体，我们感觉很臃肿，当然它的功能很强在，但有时在查看类实体时，有些麻烦，因为所有实体都在一个类文件中，有点像linq to sql，而它的类格局也与dbml有些雷同，当然这不是今天的重点，今天主要说的是当EDMX文件添.
阅读全文
摘要：回到目录无论是linq to sql 还是entity frameworks，在进行列表操作时都会有一个毛病，那就是它的操作只能一个实体一个实体的发到服务器，这样，如果列表的数量很大，如列表为１０万条数据，那么，这种操作将是非常性能的，可能你的ＤＢ就挂了。解决方案：拼接Ｔ—ＳＱＬ串，并使它具有通用性好处：与服务器建立一次连接，给服务器发一条ＳＱＬ命令，即可实现代码如下： 1 /// <summary> 2 /// 构建Insert语句串 3 /// 主键为自增时，如果主键值为0，我们将主键插入到SQL串中 4 /// </summary> 5...
阅读全文
摘要：回到目录ObjectContext作为entity framework的最原始的数据上下文对象，它的操作都是具有原始性的，没有被封闭过的，这也就难免在有些功能上欠缺一点，用过DbContext作为EF数据上下文的同学一定有留意到它的Find<TEntity>(params object[] keyValues)方法，不错,它确实比较方便，通过主键（可以是复合主键）来查找实体，这个功能在ObjectContext对象上是没有被提供的，所以，我把这个功能在ObjectContext上实现了一下，现在分享给各位： 1 /// <summary> 2 /// 根据主键得到一个实
阅读全文
摘要：回到目录相关文章系列第八回 EF架构~将数据库注释添加导入到模型实体类中第二十一回 EF架构~为EF DbContext生成的实体添加注释（T4模板应用）第二十二回 EF架构~为EF DbContext生成的实体添加注释（T5模板应用）在EF架构中，我们的数据库注释不会被自动映射到EDMX模型上，而模型的说明也不会自己在生成的SQL语句上体现，我们需要手动做一下设置才行。首先分两步走，第一步Data First环境下，将数据库注释添加到实体类；第二步 Code First环境下，将实体类注释，输出到SQL语句上。下面是实现方法：第一 数据库注释添加到实体类从数据库更新模型后，假设为"
阅读全文
摘要：产生这个问题的原因，其时是由我们的习惯引起的，一般说过，我们的update操作是这样的1 从数据表把数据获出来2 修改取出现的实体值3 发回给数据表，更新成功这看上去没有问题，但在EF环境中就会产生问题，因为当你取实体时，默认情况下EF会向ObjectStateManager提交一种跟踪机制，即向它里面添加了一个键值，而当你调用update时，这时它已经有这个键值了，所有出现异常也很正常。解决方法1：不使用上面的逻辑，直接将实体附加到数据上下文中，这是可以的解决方法2：在获取单条实体时，取消实体跟踪，扩展方法是AsNoTracking()，这时不会向ObjectStateManager添加键值
阅读全文
摘要：回到目录上回主要把数据操作规范及EF两种基类下的实现说了一下，今天主要针对ObjectContext情况下的批量操作作一个详细的说明，首先，要说明一点，批量操作不用ObjectContext提供的方法，而是使用拼SQL串的方式，将列表拼成一个SQL串，一次的发给数据库，这样在性能上绝对是一个质的飞越，本人尝试过，无论是EF还是linq to sql，它们提供的方法，对于列表的操作会产生N条SQL串（N＝列表的长度）。一个操作类型枚举：1 /// <summary>2 /// 執行SQL的類型3 /// </summary>4 pu...
阅读全文
摘要：回到目录在EF环境里，我们的数据上下文对象通常是有两个版本，一个是DbContext对象，另一个是ObjectContext，个人觉得前者是轻量级的，对于code first模式中使用比较多，而后者是原生态的，最初的EDM（entity Data Model)就是以这个为基类的，它的实现与linq to sql很类似，也是分部方法，lambda表达式等元素的产物。看看我的一个规范，两个实现吧！一个规范： 1 namespace Commons.Data 2 { 3 /// <summary> 4 /// data repository interface 5 ...
阅读全文
摘要：ADO.NET Entity Framework 是.Net Framework 3.5 SP1 引入的实体框架，它使开发人员可以通过对象模型（而不是逻辑/关系数据模型）专注于数据。实体框架Entity Framework使用概念层、映射层和逻辑层将逻辑数据库结构抽象化。ADO.NET Entity Framework是建立在关系数据库上的一种抽象概念模型(Conceptual Model)框架。术语说明：Data Source: 我们所熟知的数据库或其他可能的数据源，SQL Server、Oracle、DB2、MySQL 等等。Data Providers: ADO.NET Data Pro
阅读全文
摘要：MVC3+EF+Autofac网上这种文章确实没有，呵呵，今天就写一个，代大家分享！这个系列的文章将带我们进入一种新的开发模式，注入开发模式，或者叫它IOC模式，说起IOC你可以这样去理解它，它为你的某个实现流出一个注入点，你生产的对象，可以根据你之前的配置进行组合，这是可以的。而注入点的位置及方式也是多种多样的，我们今天主要说一个通过HTTP请求进行注入的方式，IOC工具使用高效的Autofac,对它的认识你可以看这篇文章。首先看一下我们这个项目的知识点：MVC3~一个对UI层进行分层的架构模式，在微软的MVC3中加入了开源的Razor引擎EF~这无疑是微软自己比较成功的ORM工具，它执行效
阅读全文