关于Repository、IUnitOfWork 在领域层和应用服务层之间的代码分布与实现

本来早就准备总结一下关于Repository、IUnitOfWork之间的联系以及在各层中的分布，直到看到田园里的蟋蟀发表的文章：《DDD 领域驱动设计－谈谈 Repository、IUnitOfWork 和 IDbContext 的实践》，才觉得有必要发表一下我个人的观点及其相关的实现代码，当然我的观点不一定就比他们的好，我只是表达个人观点而矣，大家勿喷。

关于Repository可以看看DUDU的这篇文章：关于Repository模式，我结合实际应用总结其核心概念为：Repository是受领域驱动及基于领域的意图对外（领域服务、领域实体、应用服务层）提供管理实体的服务，本身不对数据的持久化负责，也不应该出现未受领域约束的方法。

关于Unit Of Work，我认为它的作用是：管理数据持久化的问题，并不受外界影响（比如：并发）确保在同一个工作单元（或者说是同一个业务领域）下操作的一致性（即：要么都成功，要么就都失败），类似事务；

Entity Framework的DbContext其实就实现了Unit Of Work的功能（比如：SET用来查询数据，同时通过SET的Add及Remove向DbContext注册增加及删除的请求服务，对于更新则是通过自动适时追踪来实现的，只有通过SaveChanges才将实体的状态执行化到数据库中），于是关于在使用Entity Framework后有没有必要再实现Unit Of Work，博客园的大牛们都有过争论，我觉得应该依项目的实际情况来定，如果项目简单且不考虑更换其它数据库以及单元测试的便利性，那么直接使用DbContext就OK了，但如果不是，那么就需要用到Unit Of Work+Repository来包装隔离实际的持久化实现。

对于Repository、IUnitOfWork 在领域层和应用服务层之间的关联与代码分布，我采用如下图方式：

下面就来分享我关于Repository、IUnitOfWork 实现代码：

Exam.Domain.IUnitOfWork定义：

using System;using System.Collections.Generic;using System.Linq;using System.Text;using System.Threading.Tasks;namespace Exam.Domain{  public interface IUnitOfWork  {    IQueryable<TAggregateRoot> Entities<TAggregateRoot>()       where TAggregateRoot : class, IAggregateRoot;    void RegisterNew<TAggregateRoot>(TAggregateRoot entity)      where TAggregateRoot : class, IAggregateRoot;    void RegisterModified<TAggregateRoot>(TAggregateRoot entity)      where TAggregateRoot : class, IAggregateRoot;    void RegisterDeleted<TAggregateRoot>(TAggregateRoot entity)      where TAggregateRoot : class, IAggregateRoot;    //void RegisterClean();    void Commit();  }}

海外公司注册、海外银行开户、跨境平台代入驻、VAT、EPR等知识和在线办理：https://www.xlkjsw.com

原标题：关于Repository、IUnitOfWork 在领域层和应用服务层之间的代码分布与实现

关键词：