码迷,mamicode.com
首页 > 数据库 > 详细

Repository、IUnitOfWork和IDbContext

时间:2015-10-22 10:40:58      阅读:788      评论:0      收藏:0      [点我收藏+]

标签:

DDD 领域驱动设计-谈谈Repository、IUnitOfWork和IDbContext的实践

上一篇:《DDD 领域驱动设计-谈谈 Repository、IUnitOfWork 和 IDbContext 的实践(1)

 

阅读目录:

 

  1. 抽离 IRepository 并改造 Repository

  2. IUnitOfWork 和 Application Service 的变化

  3. 总结三种设计方案

 

简单总结上篇所做的两个改进:

 

  • 从 Repository 和 UnitOfWork 中抽离出 IDbContext,并且它们只依赖于 IDbContext。
  • Repository 和 UnitOfWork 为平级关系,UnitOfWork 负责维护对象状态(增删改),Repository 负责获取对象(查)。

 

后来,园友 Qlin 在评论中,提出了另外一种方式,大致为:

 

  • Repository 和 UnitOfWork 还是依赖于 IDbContext。
  • UnitOfWork 只有 Commit,Repository 提供对象的所有操作(增删改查)。

 

这篇文章我们就按照这种方式实现一下,关于 Repository、IUnitOfWork 和 IDbContext 的设计,以及 Application Service 的调用,上面是两种设计方案,加上上一篇博文开头说到的一种方案,我大致总结了三种,关于它们的优缺点,文章最后我再进行总结。

 

另外,关于 IDbContext 的接口设计,其实是有些模糊的,因为它并没有真正解耦 EF,比如 DbSet<TEntity> Set<TEntity>() 还是依赖于 EF,没办法,就像我们在 Repository 中返回 IQueryable,你在 Application Service 调用的时候,也必须引用 EF 一样,对于 IDbContext 来说,我们暂时把它看作是一个数据上下文容器,所有对象的持久化最后都通过它来完成,因为我们的解决方案暂时只能使用 EF,所以对于 IDbContext,我们先暂时这样设计。

 

下面我们开始进行设计。

 

1. 抽离 IRepository 并改造 Repository

 

抽离 IRepository 啥意思?我们直接来看下代码:

 

namespace DDD.Sample.Domain.IRepository
{
    public interface IRepository<TAggregateRoot> 
        where TAggregateRoot : class, IAggregateRoot
    {
        void Add(TAggregateRoot aggregateRoot);

        void Update(TAggregateRoot aggregateRoot);

        void Delete(TAggregateRoot aggregateRoot);

        TAggregateRoot Get(int id);
    }
}

 

IRepository 是一个泛型接口,类型为 IAggregateRoot,我们在里面定义了增删改查的常用操作,它的作用就是减少 Repository 的冗余代码,我们看下 IStudentRepository 的定义:

 

namespace DDD.Sample.Domain.IRepository
{
    public interface IStudentRepository : IRepository<Student>
    {
        Student GetByName(string name);
    }
}

 

IStudentRepository 需要继承 IRepository,并确定泛型类型为 Student,Student 继承自 IAggregateRoot,因为增删改查常用操作已经定义,所以我们在其它类似的 IStudentRepository 中就不需要定义了。

 

IRepository 需要进行实现,如果在 StudentRepository 中进行实现,就没有什么作用了,所以我们需要一个 BaseRepository 来实现 IRepository:

 

namespace DDD.Sample.Repository
{
    public abstract class BaseRepository<TAggregateRoot> : IRepository<TAggregateRoot>
        where TAggregateRoot : class, IAggregateRoot
    {
        public readonly IDbContext _dbContext;

        public BaseRepository(IDbContext dbContext)
        {
            _dbContext = dbContext;
        }

        public void Add(TAggregateRoot aggregateRoot)
        {
            _dbContext.Set<TAggregateRoot>().Add(aggregateRoot);
        }

        public void Update(TAggregateRoot aggregateRoot)
        {
            _dbContext.Entry<TAggregateRoot>(aggregateRoot).State = EntityState.Modified;
        }

        public void Delete(TAggregateRoot aggregateRoot)
        {
            _dbContext.Set<TAggregateRoot>().Remove(aggregateRoot);
        }

        public TAggregateRoot Get(int id)
        {
            return _dbContext.Set<TAggregateRoot>().FirstOrDefault(t => t.Id == id);
        }
    }
}

 

咋一看 BaseRepository 有点像我们上篇的 UnitOfWork,因为我们把增删改放在 Repository 了,因为 Repository 还是和 UnitOfWork 为平级关系,所以我们在 Repository 中用的 IDbContext 而非 IUnitOfWork,这个没什么问题,我们看下 StudentRepository 的具体实现:

 

namespace DDD.Sample.Repository
{
    public class StudentRepository : BaseRepository<Student>, IStudentRepository
    {
        public StudentRepository(IDbContext dbContext)
            : base(dbContext)
        {
        }

        public Student GetByName(string name)
        {
            return base._dbContext.Set<Student>().Where(x => x.Name == name).FirstOrDefault();
        }
    }
}

 

StudentRepository 很简单,因为常用操作 BaseRepository 已经实现了,base(dbContext) 的作用就是给 BaseRepository 注入 IDbContext 对象。

 

Repository 的改造基本上就这些,表面看起来确实很好,另外,如果没有 IUnitOfWork 和 Application Service,我们对 Domain 进行单元测试,也是能满足我们的需求,但需要将 IDbContext 再进行修改下。

 

2. IUnitOfWork 和 Application Service 的变化

 

我们先看下 IUnitOfWork 的变化,直接贴下代码:

 

namespace DDD.Sample.Infrastructure.Interfaces
{
    public interface IUnitOfWork
    {
        bool Commit();

        void Rollback();
    }
}

 

因为增删改都移到 Repository 中了,所以 IUnitOfWork 的工作就很简单,只有 Commit 和 Rollback,实现也比较简单,我们看下:

 

namespace DDD.Sample.Infrastructure
{
    public class UnitOfWork : IUnitOfWork
    {
        private IDbContext _dbContext;

        public UnitOfWork(IDbContext dbContext)
        {
            _dbContext = dbContext;
        }

        public bool Commit()
        {
            return _dbContext.SaveChanges() > 0;
        }

        public void Rollback()
        {
            throw new NotImplementedException();
        }
    }
}

 

这个没啥说的,我们直接看下 Application Service 的代码:

 

namespace DDD.Sample.Application
{
    public class StudentService : IStudentService
    {
        private IUnitOfWork _unitOfWork;
        private IStudentRepository _studentRepository;
        private ITeacherRepository _teacherRepository;

        public StudentService(IUnitOfWork unitOfWork, 
            IStudentRepository studentRepository,
            ITeacherRepository teacherRepository)
        {
            _unitOfWork = unitOfWork;
            _studentRepository = studentRepository;
            _teacherRepository = teacherRepository;
        }

        public Student Get(int id)
        {
            return _studentRepository.Get(id);
        }

        public bool Add(string name)
        {
            var student = new Student { Name = name };
            var teacher = _teacherRepository.Get(1);
            teacher.StudentCount++;

            _studentRepository.Add(student);
            _teacherRepository.Update(teacher);
            return _unitOfWork.Commit();
        }
    }
}

 

StudentService 其实变化不大,只是将原来的 unitOfWork 添加修改操作,改成了 studentRepository 和 _teacherRepository,执行下 StudentService.Add 的单元测试代码,发现执行不通过,为什么呢?因为 Repository 和 UnitOfWork 的 IDbContext 不是同一个对象,添加修改对象通过 Repository 注册到 IDbContext 中,最后 UnitOfWork 执行 Commit 却是另一个 IDbContext,所以我们需要确保 Repository 和 UnitOfWork 共享一个 IDbContext 对象,怎么实现呢?

 

我们进行改造下:

 

namespace DDD.Sample.Application
{
    public class StudentService : IStudentService
    {
        private IDbContext _dbContext;
        private IUnitOfWork _unitOfWork;
        private IStudentRepository _studentRepository;
        private ITeacherRepository _teacherRepository;

        public StudentService(IDbContext dbContext)
        {
            _dbContext = dbContext;
        }

        public Student Get(int id)
        {
            _studentRepository = new StudentRepository(_dbContext);
            return _studentRepository.Get(id);
        }

        public bool Add(string name)
        {
            _unitOfWork = new UnitOfWork(_dbContext);
            _studentRepository = new StudentRepository(_dbContext);
            _teacherRepository = new TeacherRepository(_dbContext);

            var student = new Student { Name = name };
            var teacher = _teacherRepository.Get(1);
            teacher.StudentCount++;

            _studentRepository.Add(student);
            _teacherRepository.Update(teacher);
            return _unitOfWork.Commit();
        }
    }
}

 

上面对应的测试代码执行通过,其实解决方式很简单,就是手动给 UnitOfWork、StudentRepository 和 TeacherRepository 注入相同的 IDbContext 对象,当然这是一种解决方式,还有人喜欢用属性注入,这都是可以的,无非最后就是想让 Repository 和 UnitOfWork 共享一个 IDbContext 对象。

 

本篇的相关代码已提交到 GitHub,大家可以参考下:https://github.com/yuezhongxin/DDD.Sample

 

3. 总结三种设计方案

 

关于 Repository、IUnitOfWork 和 IDbContext 的设计,以及 Application Service 的调用,我总结了三种设计方式,我觉得也是我们常用的几种方式,下面我大致分别说下。

 

1. IUnitOfWork -> EfUnitOfWork -> Repository -> Application Service

 

这种设计应该我们最熟悉,因为我们一开始就是这样设计的,但问题也是最多的,要不然我也不会写上一篇博文了,比如存在的问题:

 

  • IUnitOfWork 的职责不明确。
  • Repository 的职责不明确。
  • Application Service 很困惑,因为它不知道该使用谁。
  • Application Service 的代码越来越乱。
  • ....

 

上一篇博文最后分析出来是 IUnitOfWork 的设计问题,因为它做了太多的事,并且 Repository 依赖于 IUnitOfWork,以至于最后在 Application Service 的调用中,Repository 显得非常多余,这种设计最大的问题就是职责不明确

 

2. IDbContext -> IUnitOfWork/IRepository(only query) -> UnitOfWork/Repository -> Application Service

 

第二种设计是我比较倾向于的,因为第一种设计出现的问题,所以我对 IUnitOfWork 的设计非常看重,并且我读了《企业应用架构模式》中关于 UnitOfWork 的所有内容,其实就那么几个字可以概括:维护对象状态,统一提交更改。我个人觉得架构设计最重要的地方就是底层接口的设计,就像我们盖一栋摩天大楼,如果地基打不稳,最后的结果肯定是垮塌,所以,我比较坚持 IUnitOfWork 这样的设计:

 

技术分享

 

相对于第一种设计,这种设计还有一个不同就是 IUnitOfWork 和 IRepository 为平级关系,为什么这样设计?因为我们不能通过 IUnitOfWork 提供查询操作,并且 IUnitOfWork 和 ORM 也没什么关系,所以我们最后抽离出来一个 IDbContext,并且用 EF 去实现它。

 

IRepository 只有查询,这是我们的定义,在 Application Service 的调用中,对象的新增和修改都是通过 IUnitOfWork 进行实现的,因为查询并不需要记录状态,所以我们并不需要将 IDbContext 在 IUnitOfWork 和 IRepository 之间进行共享,有人会说,IRepository 应该提供领域对象的增删改操作啊,我们再看下 Repository 的定义:协调领域和数据映射层,利用类似于集合的接口来访问领域对象。

 

集合访问领域对象,那 Repository 如果这样设计呢:

 

public class StudentRepository : IStudentRepository
{
    private IQueryable<Student> _students;

    public StudentRepository(IDbContext dbContext)
    {
        _students = dbContext.Set<Student>();
    }

    public Student GetByName(string name)
    {
        return _students.Where(x => x.Name == name).FirstOrDefault();
    }
}

 

这种 Repository 设计是比较符合定义的,另外,我们如果对 Domain 进行单元测试,集合性质的领域对象也是可以进行维护的,只不过没有持久化而已。

 

总的来说,第二种设计最大的优点就是职责明确,你想干坏事也干不了(因为接口已经被约束),目前来说没发现什么问题。

 

3. IDbContext -> IUnitOfWork(only commit)/IRepository -> UnitOfWork/Repository -> Application Service

 

第三种设计就是本篇博文讲述的,它其实是从第一种和第二种之间取一个中间值,做了一些妥协工作,具体的实现,上面已经详细说明了,我最接受不了的是对 IUnitOfWork 的更改,虽然表面看起来蛮好的,但我总觉得有些不对劲的地方,就像我们“迫于现实做一些违背道德的事”,可能现在觉察不到什么,但出来混的总是要还的。

 

关于 Repository、IUnitOfWork 和 IDbContext 的设计,以及 Application Service 的调用,我觉得应该是我们在 DDD 架构设计过程中,最普遍遇到的一个问题,但也是最困惑的一个问题,比如最近两个园友写的博文:

 

 

对于本篇博文,如果你有什么问题或疑问,欢迎探讨学习。:)

Repository、IUnitOfWork和IDbContext

标签:

原文地址:http://www.cnblogs.com/Leo_wl/p/4899837.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!