关于 Repository和UnitOfWork 模式的关系

标签：

本以为，关于这方面的理解，园子中的文章已经很多的了，再多做文章真的就“多做文章了”，但是最近发现，还是有必要的，首先，每个人对于同一事物的理解方式和出发点都是不同的，所以思考的方式得到结果也是不同的。另外鉴于网友 @白细胞 的需求，需要对这方面的理解，索性写写，时间有些紧张，所有拖了两天，抱歉。

首先，在此说明，本人从未有人教过，也没有在公司的项目中使用过这些内容，原因很简单，ZF的东西，用不到这些，实属无奈直觉，而本人却相当，甚至放荡的喜好这些东西，曾经~~不知道怎么就明白了，实属不想知道，但是~~我废话真多哦。结束~~~

以下分三点简要讲述：1，repository模式 2，UnitOfWork模式，3,二者常用关系

一，repository模式 

     描述和作用：

           按照最初提出者的介绍，它是衔接数据映射层和域之间的一个纽带，作用相当于一个在内存中的域对象集合。客户端对象把查询的一些实体进行组合，并把它们提交给Repository。对象能够从Repository中移除或者添加，就好比这些对象在一个Collection对象上就行数据操作，同时映射层的代码会对应的从数据库中取出相应的数据。

从概念上讲，Repository是把一个数据存储区的数据给封装成对象的集合并提供了对这些集合的操作。。。。。。。

在领域驱动设计中，我们有个集合(aggregate)的概念， 通常我们是对于domain的每个集合会对应的定义一个repository。也就说，并不是每个实体都会有对应的一个repository。（假设这是一个仓库，简介源自网上摘录。。）

二，UnitOfWork模式

     描述和作用：

           简说了，主要作用是在数据持久化过程中，数据提，确保数据的完整性，对象使用确保同一上下文对象。如果有异常，提供回滚。

三，二者的关系

      目前本人的理解方式，当然这个理解也琢磨了好久，看了好多开源和案例才确定的，以前一直很含糊，也被模糊、勾引过。

关系即：

      工作单元服务于仓储，并在工作单元中初始化上下文，为仓储单元提供上下文对象，由此确保同一上下文对象。

      那么此时，问题来了，怎么在仓储中获取上下文。（使用的orm为 EF，以autofac或者MEF实现注入，以此为例） 所以，此时实现就变得很简单。

      看脚本：

      UOW中

        在uow中初始化上下文对象，定义了Context的属性对象（当然，这地方可以不初始化，可以有IOC在注入时候带入参数注入，详见IOC，常见方式就几种，实现方式也很类似。） 此处如果看的觉得不爽，换成DbSet对象也可，您请随意。

       repository中

       在仓储构造函数中，默认初始化仓储对象和获取上下文对象，好像讲完了，没有了~~~~

以下是本人目前的，我可以说写着玩的吗？就是比较喜爱，但是有弊端，用久了就发觉了，二者组合不是很合适，尽管很多人推崇。当然好处显而易见，就是提供了统一的开发模式和规范，是开发人员的开发方式更具规则性 ，更好维护。

         uow:

         public OlympicOverDbContext Context {get{......初始化上下文}}

       repository仓储：

....增改删，略....

       如有理解不当之处，还各位大哥哥能指出，多多赐教，谢谢。 

关于 Repository和UnitOfWork 模式的关系

标签：

原文地址：http://www.cnblogs.com/Tmc-Blog/p/4940707.html