关于Repository和UnitOfWork模式的关系

以下分三点简要讲述：

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 
    {
        ......初始化上下文
    }
}
public bool IsCommitted { get;set;}

public int Commit() 
{
    if (IsCommitted) return 0;
    try 
    {
        int result = Context.SaveChanges();
        IsCommitted = true;
        return result;
    }
    catch (DbEntityValidationException advEx) 
    {
        ...捕捉异常
        return -1;
    }
}
public void RollBack() 
{
    IsCommitted = false;
}
public void Dispose() 
{
    if (!IsCommitted) 
    {
        Commit();
    }
    Context.Dispose();
}

repository仓储：

public OlympicOverRepository(IUnitOfWork unitOfWork) 
{
    UnitOfWork = unitOfWork;
    //Context = unitOfWork.GetDbContext;
    Context = ((UnitOfWork.UnitOfWork)unitOfWork).Context;
}

#region 属性
/// 

///     获取仓储上下文的实例
/// 
public IUnitOfWork UnitOfWork 
{
    get;
}

/// 

/// 数据上下文
/// 
protected DbContext Context 
{
    get;
    private set;
}

/// 

/// 获取  当前实体的查询数据集
/// 
public IQueryable Entities 
{
    get 
    {
        return Context.Set();
    }
}
#endregion

….增改删，略….

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