文章提纲

• 概述要点
• 理论基础
• 详细步骤
• 总结

概述要点

设计模式的产生，就是在对开发过程进行不断的抽象。

我们先看一下之前访问数据的典型过程。

在Controller中定义一个Context, 例如：

private AccountContext db = new AccountContext();

在Action中访问，例如获取用户列表：

var users=db.SysUsers;

 

类似于这种，耦合性太高。业务逻辑直接访问数据存储层会导致一些问题，如

重复代码；不容易集中使用数据相关策略，例如缓存；后续维护，修改增加新功能不方便 等等。

 

我们使用repository来将业务层和数据实体层分开来，业务逻辑层应该对组成数据源层的数据类型不可知，比如数据源可能是数据库或者Web service

在数据源层和业务层之间增加一个repository层进行协调，有如下作用：

1.从数据源中查询数据

2.映射数据到业务实体

3.将业务实体数据的修改保存到数据源 （持久化数据）

这样repository就将业务逻辑和基础数据源的交互进行了分隔。

数据和业务层的分离有如下三个优点：

1.集中管理不同的底层数据源逻辑。

2.给单元测试提供分离点。

3.提供弹性架构，整体设计可以适应程序的不断进化。

我们将会对原有做法进行两轮抽象，实现我们想要的效果。

 

理论基础

仓储和工作单元模式是用来在数据访问层和业务逻辑层之间创建一个抽象层。

应用这些模式，可以帮助用来隔离你的程序在数据存储变化。

 

 

下图比较了不使用库模式和使用库模式时controller和context 交互方式的差异。

说明：库模式的实现有多种做法，下图是其中一种。

 

 

准备工作

首先我们先搭建好空的框架，准备基本的结构和一些测试数据。

我们不再在第一阶段的MVCDemo上进行更改了， 重新建立一个新项目XEngine作为我们第二阶段的演示项目 。

1.新建项目

 

2.新建Model

我们新建 SysUser, SysRole , SysUserRole

 

3. 安装EF, 准备测试数据

a.安装EF

b.新建文件夹DAL

à 新建类 XEngineContext.cs

à 新建类 XEngineInitializer.cs

 

c.修改HomeController.cs，运行Index视图，来生成数据库结构和测试数据。

说明：准备工作有不清楚的请参考第三篇文章：

http://www.cnblogs.com/miro/p/4053473.html

 

至此，准备工作已经OK，下面就看看如何运用仓储模式来改造我们的项目。

 

详细步骤

整个过程分成两轮抽象。

第一轮抽象 ： 解耦Controller和数据层

对每一个实体类型建立一个对应的仓储类。

以SysUser来说，新建一个仓储接口和仓储类。

在controller中通过类似于下面这种方式使用：

ISysUserRepository sysUserRepository = new SysUserRepository();

 

下面来看创建 SysUser 仓储类具体做法：

1.新建个文件夹 Repositories， 后面新建的仓储类都放在这个文件夹中

 

2.创建接口 ISysUserRepository

接口中声明了一组典型的CRUD方法。

其中查找方法有两个：返回全部和根据ID返回单个。

 

 

 

3.创建对应的仓储类 SysUserRepository

创建类 SysUserRepository， 实现接口 ISysUserRepository

a. 把接口中的方法全部实现

 

b.关闭连接

 

说明：

GC.SuppressFinalize(this);

因为对象会被Dispose释放，所以需要调用GC.SuppressFinalize来让对象脱离终止队列，防止对象终止被执行两次。

 

 

 

 

 

 

 

4.Controller中使用SysUser仓储类

我们新建个Controller : UserController

用 List 模板生成视图。

 

修改Controller如下：

 

运行Index就可以看到用户列表了。

 

 

 

更新和删除就不再举例了，都比较简单，大家可以自己去试验，方法类似。

至此，第一次抽象就完成了。

可以看到，我们增加了一个抽象层，将数据连接的部分移到Repository中去，这样实现了Controller和数据层的解耦。

 

观察一下可以发现，还存在两个问题：

1.如果一个controller中用到多个repositories，每个都会产生一个单独的context

2.每个entity type 都要实现一个对应的repository class ，这样会产生代码冗余。

下面我们就再进行一次抽象，解决这两个问题。

说明：

为方便讲述，实体类型 和 仓储类 以下直接用 entity type 和 repository class表示。

 

 

 

第二轮抽象：通过泛型消除冗余的repository class

为每个 entity type 创建一个repository class 会

a. 产生很多冗余代码

b. 会导致不一致地更新

举例：

你要在一个 transaction中更新两个不同的 entity type

如果使用不同的context instance, 一个可能成功，另外一个可能失败。

 

我们使用 generic repository去除冗余代码

使用unit of work保证所有repositories使用同一个 context

说明：

后面将会新建一个unit of work class 用来协调多个repositories工作， 通过创建单一的context让大家共享。

 

 

一、首先解决代码冗余的问题。

我们对ISysUserRepository和SysUserRepository 再进行一次抽象，去除repository class的冗余。

 

仿照ISysUserRepository和SysUserRepository，新建IGenericRepository和GenericRepository

步骤和前面类似：

1. 创建泛型接口 IGenericRepository

下图中右边为IGenericRepository， 大家观察下两者的区别

2.创建对应的泛型仓储类 GenericRepository

下面折叠起来的部分没有任何变化。

 

3.修改UserController

把原来的注释掉，给泛型类指定SysUser，主要更改部分如红线表示。前端不用做任何更改。

 

运行Index就可以看到和之前一样的结果了。

&nbs