您的位置:首页 > 其它

一步一步学EF系列 【7、结合IOC ,Repository,UnitOfWork来完成框架的搭建】

2016-11-24 11:49 363 查看
前言

距离上一篇已经有段时间了,最近这段时间赶上新项目开发,一直没有时间来写。之前的几篇文章,主要把EF的基础都讲了一遍,这批文章就来个实战篇。

个人在学习过程中参考博客:

Entity Framework技术系列

EF-Code First(1):Repository,UnitOfWork,DbContext

Repository

在数据库系统中,对于数据层来说,所有的操作归根结底无非“C(增加)、R(读取)、U(修改)、D(删除)”这四种操作。四种操作当中,与与业务相关度最大的是读取操作,根据各种不同的业务需求提交不同的查询,其最终执行应该放到业务层面中去进行,而增加,修改,删除这三种操作较为通用,可以作为通用数据操作封装到Repository中。在Repository中,唯一的变化点就是各种不同的实体类型,既然是变化点就应该进行封装,这里使用泛型来封装这个变化点。

还要说明一下,每个操作方法都带有一个 isSave 可选参数,是为了单个实体操作的需要,免去了每次都要调用 context.SaveChanged()的麻烦。如果是进行多个实体的单元事务操作,就需要把这个参数设置为 false 。

这里面就是定义了一个实体的增删改查。

Repository的通用实现如下:

实现类中所有操作最终都是通过单元操作来提交的,关于单元操作,接下来。这里用到了IOC,不懂的可以看之前的文章


UnitOfWork

 引入单元操作,主要是为了给各个实体维护一个共同的DbContext上下文对象,保证所有的操作都是在共同的上下文中进行的。EF的操作提交 context.SaveChanged() 默认就是事务性的,只要保证了当前的所有实体的操作都是在一个共同的上下文中进行的,就实现了事务操作了。

在业务层中,各个实体的增删改操作都是通过各个实体的Repository进行的,只需要提供一个提交保存的功能作为最后调用,即可保证当前的提交是事务性的。因此定义给业务层引用的单元操作接口如下:



在数据组件内部,数据操作最终都提交到一个与IUnitOfWork接口的实现类中进行操作,以保证各个实体的Repository与IUnitOfWork使用的是同一个DbContext上下文。定义数据单元操作接口如下:

在单元操作的实现基类中,定义一个只读的DbContext抽象属性,实际的DbContext上下文需要在实现类中进行重写赋值。

业务整合





首先看接口的定义 ,他需要继承仓储接口

实现类继承仓储的基类

主要看一下使用,这里使用的是属性注入,然后就可以调用了

前端页面 OK完成,。

结束语

本文最难理解的就是这个思路,如果能看懂的肯定会发现不足的地方,后面也准备了一个升级篇。不懂的可以加入下面的QQ群进行交流,源代码也已经上传到群共享文件了。欢迎下载。

大家也可以加入QQ群进行交流(435498053)。

作者:STONE刘先生 出处:http://www.cnblogs.com/liupeng/
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐