随笔分类 - 其它 / Entity Framework
微软即linq to sql之后又一个成功的ORM软件，它可以生成三种ORM方式，如数据优先，代码优先和模型优先
摘要：回到目录Entityframeworks很聪明不错，非常不错！ef里的contains比linq to sql里的contains有了明显的提升，事实上，是在进行ＳＱＬ语句翻译上有所提升，在linq to sql里不支持iqueryable的contains集合，它只支持本地集合进行contains，而本地集合的contains会被.net翻译成sql语句是where in (...)，即集合有多个元素，在in里就会被列举多少次，这个在性能上是非常低下的，不提倡的，而且它还有长度限制，最多本地集合在linq to sql里是２０００多个元素。ef在这点上表示不错，它为了防止你使用低下的查询，它
阅读全文
摘要：回到目录对于transactionscope不了解的同学，可以看我的相关文章第二十六回 将不确定变为确定~transactionscope何时提升为分布式事务？第二十七回 将不确定变为确定~transactionscope何时提升为分布式事务~续第二十八回 将不确定变为确定~transactionscope何时提升为分布式事务~再续（避免引起不必要的ＭＳＤＴＣ）第二十九回 将不确定变为确定~transactionscope何时提升为分布式事务~大结局第三十七回 将不确定变为确定~transactionscope何时提升为分布式事务~SQL2005与SQL2008不同声明：对于这种事务，如果..
阅读全文
摘要：回到目录对ＥＦ开发来说，导航属性肯定都用过，事实上，它是由ＶＳ ＩＤＥ工具根据你的数据库关系结构自动生成的外键属性，在类视图中可以看到相关属性，它是以外键表名来标识的，如果是一对多的关系，那么，它会为属性加上ICollection泛型集合用来标识，而今天我们要说的当然不是自动生成的，而是手动加的属性，这样属性需要我们手动进行join，然后把它按需赋值，而使用include当然是无效的，呵呵。一般地，我们习惯上把集合属性定义为List，但是，对于linq to entities来说，这个东西并不是很受欢迎，而标准结果集大家都知道是IEnumerable，它是所有集合的基类，自身只提供了集合遍历的
阅读全文
摘要：回到目录这个标题很有意思，关系表插入，就是说主表和外表键在插入时，可能会有同步插的情况，如在建立主表时，扩展表需要同步完成数据的初始化工作，而对于多表插入时，我们为了保证数据的一致性会针它写在事务中，而对于.net中的事件，它在一些情况下，会不那么单纯，对于ef和linq to sql来说，你的事务如果出现多次提交动作（submitchange | savechanges），那么,.net这边会把它提升为分布式事务（ＭＳＤＴＣ），即.net认为，对于一个数据表的操作，不会出现多个savechanges，ＯＫ，这个可以解释的通，一个数据库，一个提交，这是符合性能要求的，呵呵，但对于我们的架构来说
阅读全文
摘要：回到目录一般地，网站出现异常后，我们会通过设置web.config的方法来实现友好页的显示，这个方法比较常用，但捕捉的信息不是很具体，在程序测试阶段，我们可以通过global.asax来实现友好的，详细的异常信息的显示，下面来看一下。WEB.CONFIG里的实现： - 而这种方式不能把具体出错的信息显示出来，这在网站运营阶段是可以接受的，但在网站测试阶段是不可以的，下面看看我的global.asax方法： protected void Application_Error(object sender, EventArgs e) { ...
阅读全文
摘要：回到目录今天在进行EF开发时，遇到一个问题，在进行join查询时，类中的一个集合类型的导航属性，在给它赋值时，将查询出来的结果ToList()后，出错了，linq to entity不支持这种操作，而在linq to sql里这是合法的，在EF中是不行的，所以，使用了替换方法，就是类型强转，代码如下： var linq = from student in base.GetModel() join user_classrooms in new TsingDa_NewLearningBarRepository(base.UnitWork).GetMode...
阅读全文
摘要：回到目录对于SQL左外连接我想没什么可说的,left join将左表数据都获出来,右表数据如果在左表中不存在,结果为NULL,而对于LINQ来说,要实现left join的效果,也是可以的,在进行join时直接into到集合变量就可以了,但在赋值时,如果只需要集合的一条记录,那在写法上又会有两种,而这两种写法所产生的性能是相关千里的,下面来看一下.首先是SQL的左外连接SELECT [t6].[CourseID] , [t6].[UserID] , [t6].[CourseName] , [t6].[ResourceID] , [t6]...
阅读全文
摘要：回到目录AutoMapper在之前我曾经介绍过，今天主要是把它作一下扩展，因为它的调用太麻烦了，呵呵，扩展之后，用着还可以，感觉.net3.5之后，有了扩展方法这个东西，在程序开发速度及表现力上都有了明显的提升，呵呵。当扩展方法开发完之后的效果如下实体对实体的映射（赋值） var user = new User { ID = 1, Name = "zzl", CreateDate = DateTime.Now, }; UserModel...
阅读全文
摘要：回到目录在设计表结构时，我们通常将不是很在乎表现的主键设计成自增长的，大数据量用bigint，一般地用int就可以了，int就是C#里的Int32，它最大可以存储到2147483647,21亿，基本可以满足大多数的要求了，呵呵。对于自增长主键来说，导数据是个比较麻烦的事，使用SQLSERVER还可以，你把自增去了，再进行SQL专入即可，但如果导数据这个动作是作到程序里，那可就有点麻烦了，一般地，我们为自增主键数据表导数据时，有两个方式，一是去掉自增长特性，二是使用SQL提交的SET IDENTITY_INSERT [table] ON/OFF，如果你的导数据动作是在程序里完成的，那就只能使用后
阅读全文
摘要：回到目录在编程世界里，使用“否定式”不是一件好事，因为它的可读性并不高，但有时，为了让使用者减少代码量，还是使用了双重否定，直到DefaultValue的出现，它改变了这一切，它可以为你的属性设置你想要的默认值，如bool类型默认值是false，而如果你希望它的默认值是true，就需要用到DefaultValue这个特性了。这是我IUnitOfWork代码片断 /// /// 工作单元 /// 提供一个保存方法，它可以对调用层公开，为了减少连库次数 /// public interface IUnitOfWork { /// ...
阅读全文
摘要：回到目录对于大数据量提交，包括插入，更新和删除，我始终不建议用ＥＦ自带的方法，因为它会增加与数据库的交互次数，一般地，ＥＦ的一个上下文在提交时会打开一个数据连接，然后把转换成的ＳＱＬ语句一条一条的发到数据库端，然后去提交，试想，如果你的数据量达到万级别（更不用说百万，千万数据了），那对数据库的压力是很大的，所以，我将ＥＦ批量操作语句进行了改版，并起名为BulkInsert,BulkUpdate和BulkDelete，事实上，在我之前的版本中并没有涉及到批次提交的概念，直到遇到了实际的问题，当你使用BulkInsert时，如果数据达到４万之前，那在SQL的解释时，也是很有压力的，有多情况下会超时
阅读全文
摘要：事情是这样的，有一个列表，里面有很多用户信息，可能会有重复的用户，将这个列表的用户插入到数据表中，如果用户已经存在，就更新这个用户的FillTimes 字段，让它加１，使用的底层ＯＲＭ是entity frameworks4。这是方法的大概内容 var user_Account = iC_User_Account.Find(i => i.UserID == u.UserID); if (user_Account == null) { iRepository.Insert(new C_User_Acco...
阅读全文
摘要：回到目录AutoMapper是一个.NET的对象映射工具，一般地，我们进行面向服务的开发时，都会涉及到DTO的概念，即数据传输对象，而为了减少系统的负载，一般我们不会把整个表的字段作为传输的数据，而是单独根据具体场景，写一个新的类，这个类一般以DTO结尾，意思是说，它是网络上的数据传输用的，而你的DTO数据对象的赋值过程就成了一个问题，而为了减少赋值过程的代码量，AutoMapper就出来了，它可以实现实体对实体的赋值过程，或者叫“映射过程”。我心中的项目应该是这样的，用户业务服务，产品业务服务，订单业务服务，这样服务都使 用单独的数据库，它们之间的通讯采用WCF进行实现，在获数据时会在WEB
阅读全文
摘要：回到目录相关文章系列第八回 EF架构~将数据库注释添加导入到模型实体类中第二十一回 EF架构~为EF DbContext生成的实体添加注释（T4模板应用）第二十二回 EF架构~为EF DbContext生成的实体添加注释（T5模板应用）嗨，没法说，EF4的TT模版加上注释后，升级到EF5的TT模版后，注释就不通用了，所以，还得再研究一下，然后把操作方法再分享出来，没辙的微软！T4模版可能有些凌乱，这在T5模版里有了不错的改进，但我希望解决的问题在T5里并没有得到解决，那就是TT类文件自动得到EDMX模型的注释问题，可能大微的开发人员不需要实体注释吧，嗨！1 先加上类注释找到这行代码Write.
阅读全文
摘要：回到目录对于从linq to sql迁移过来的开发者，对随机排序不会感到陌生，直接为datacontext添加一个方法再配合反射就可以实现随机排序了，代码如下： /// /// 数据上下文扩展 /// public partial class dbDataContext : IUnitOfWork { /// /// 随机排序时使用这个函数 /// /// [Function(Name = "NewID", IsComposable = true)] public Gui...
阅读全文
摘要：回到目录规约(Specification)模式：第一次看到这东西是在microsoft NLayer项目中，它是微软对DDD的解说，就像petshop告诉了我们MVC如何使用一样，这个规约模式最重要的作用是实现了查询语句与查询条件的分离，查询语句在底层是稳定的，不变的，而查询条件是和具体业务，具体领域有关的，是易变的，如果我们为每一个领域的每一个新需求都写一个新的方法，那就会出现很多重复的代码，不利于程序的最终扩展！下面我们来看一个经典例子一个IOrderRepository的接口，定义了一个订单仓储 Order_Info GetOrder_InfoById(int orderI...
阅读全文
摘要：对于多对多关系，我们需要引入第三张表，一般我们称它为关系表，关系表不需要自已的主键，而是通过相关表的主键进行组合，我们一般称为多主键，下面看一下菜单表与角色表，它们是一种多对多关系的结构。一般地，我们手动更新多对多关系表时，方法是：删除原来关系，插入新关系，而EF的作法不是这样，它是先比较现在有集合与数据表里的内容是否相同，如果相同不进行操作，如果没有就插入，如果有就删除，性能上有了一个提升！在EF的模型中，这种多对多的纯关系把不会出现在模型里，而是直接用实体集合代替，这样关系更直接了，觉得这种设计不错在MVC架构开发中，需要注意的是，你的集合对象的表单元素名称必须写完整，如果是role下面的
阅读全文
摘要：回到目录单表一对多关系很常见，它是一种树形结构，如系统菜单表，部门表，分类表，这些都可以做成单表一对多关系，而这些表做成一对多关系后，如果通过EntityFramework进行插入操作时，会很方便，EF会自动为我们确实上级ID，对于操作的性能也是可以接受的，与数据库建立一次链接，发一批指定，这是我们可以接受的，虽然在性能上不是最佳的，但综合对比来看，它即是最佳的。（结合对比＝程序性能+开发人员工时+程序扩展性+程序可读性）OK，我们以菜单表为例，说一下这个菜单表初始化的过程对于菜单实体的赋值，看一下代码：var menu = new WebManageMenus ...
阅读全文
摘要：回到目录用工作单元带给我们的是什么？... 11. 相关说明2. 优化查询3. 优化SubmitChanges4. 优化TransactionScope5. 核心代码1. 相关说明工作单元的接入，保证了数据上下文在一个操作单元中只有一个，它可以通过构造方法注入到其它类中，实现跨类进行方法的组合。2. 优化查询上面的问题产生的场合应该是：你用了join语句，你的join语句与from语句所使用的数据上下文不是一个（DataContext）解决方法：将数据上下文变成一个就可以了，这就是之前我们一直用的线程单例模式出现的原因，而往往一个方法可能需要引用多个类中的方法，这时，线程单例将不能解决这个问题
阅读全文
摘要：回到占占推荐博客索引经过两周的努力，终于把这个系列写完了，这段时候正好赶上项目改版，所以也像自己的项目重构了一下，将IUnitOfWork思想注入其中，希望对系统有所帮助，那是必然的，呵呵，IUnitOfWork的出现主要还是体现在性能上，下面看一下目录：说说IUnitOfWork~目录第一讲 说说IUnitOfWork~认识IUnitOfWork，为什么要出现IUnitOfWork接口第二讲 说说IUnitOfWork~Linq to Sql与EntityFrameworks中的SubmtChanges()发生了什么事第三讲 说说IUnitOfWork~方法完整性与统一提交不冲突第四讲...
阅读全文