标签：enc 引用 es2017 abs blank 逻辑 更换 编程 属性
一、前言
UnifOfWork模式，一般称为“工作单元”模式，是DDD(Domain-Driven Design，领域驱动设计)的一个组成部分，用于在应用服务方法中，控制一个应用服务方法的所有数据库操作，都在一个事务内。最近对个人的一个Web项目进行了改造，按照DDD的设计模式进行了分层，虽然在领域层没有实现完整的领域对象（实体+值对象+领域服务 ）,但是DDD也并不是铁板一块，架构设计指南最终也是要服务于具体项目的，领悟思想为我所用才是一个提高的过程，记录下来，以备日后温习。
二、DDD模式分析
经典的DDD架构，由如图四层组成，第一层是用户层，是直接面向用户的UI界面层，放到开发环境中，可以指代比如浏览器前端、移动端APP、Windows客户端等。第二层是指应用服务层，这层直接面向的是现实的需求，比如某公司的“新员工入职”，这一层根据DDD理论，应该是很薄的一层，主要是组合领域层中的不同对象，来实现最终的现实需求。本文主要实现的UnitOfWork也是在这一层。
第三层领域层，这是整个系统中最核心的一层，表达了业务的逻辑，按照通用语言、和使用通用语言对于业务范围进行限界上下文的划分，划分出一块一块的领域出来，并使用“实体对象、值对象、Repository、领域服务”等概念进行组织。其中Repository应该是抽象的接口，为了解耦合具体的ORM，Repository模式应该是在领域层定义接口、在第四层基础设施层实现（以备日后可能的进行更换ORM行为）。
第四层基础设施层，是项目中一些具体底层操作的实现，比如领域层的Repository的实现，文件的保存，邮件的发送，等等。
领域驱动设计是一门精深的学问，以上只简单介绍，如果有兴趣，可以去看看这两本书： 《领域驱动设计 软件核心复杂性应对之道》《实现领域驱动设计》。
三、项目分层简介
个人的项目规模也不大，但是会有“在同一次Http请求内同一事务内组合业务逻辑”的需求，结合ASP.NET的已有功能，分层如下：
用户界面层：Web SPA（Angular、React等，前端分离另行开发，故VS中不会有相关的项目）
应用服务层：ASP.NET WebAPI
领域层：一个单独的类库项目，定义Model（贫血模型，只包含属性）、服务的接口IXXXService以及其实现XXXService，仓储接口IRepository。
基础设施层：一个单独的类库项目：实现了领域层中定义的IRepository，目前已有了EF以及Dapper的两种实现。
项目引用（依赖）顺序：最顶层是领域层，无任何依赖；应用访问层（WebAPI）依赖领域层以及基础设施层。
在领域层中，我定义如下两种基础接口，其中IUnitOfWork接口包含一个虚拟事务对象、以及一个Commit()方法。IRepository对象用于实现对于每一个实体（model或者叫entity都可以）的持久化操作，处于简单期间并没有加入比如分页查询方法等。
public interface IUnitOfWork { /// <summary> /// 事务对象，Dapper为IDbTransaction,EF为DbContext /// </summary> object VirtualTransaction { get; } void Commit(); } public interface IRepository<T> where T:class { int Insert(T t); T Get(string id); int Update(T t); int Delete(T t); }
因为ASP.NET Core自带了一个方便的IOC容器，可以实现Transient（每次使用都创建新的对象）、Scope（每个Http请求内只创建唯一的对象）、Singletion（单例）三种生命周期的依赖注入，结合ASP.NET的工作原理：对于每一个Http请求，都会实例化一个Controller对其处理，因此我们可以进行如下设计：
在ASP.NET Core的StartUp中，将IUnitOfWork与其实现类UnitOfwork，进行Scope方式注入。
这样，每次Http请求中，因为自始至终只会有一个UnitOfWork对象，这个对象里面保存着一个用于事务的对象（EF是DbContext，Dapper是IDBTransaction），在Action结束的时候，调用UnitOfWork的Commit()方法，进行提交，即实现了每个Controller中只会有一个事务。
//UnitOfWork会被注入到Repo对象中，Repo对象会被注入到Service对象中，Service对象会被注入到Controller对象中
services.AddScoped<IUnitOfWork,UnitOfWork>();
services.AddScoped<IUserRepository, UserRepository>();
services.AddScoped<IBookRepository, BookRepository>();
services.AddScoped<IAccountService, AccountService>();
services.AddScoped<IPublishService, PublishService>();
再贴一下我的Controller的示意代码
[Route("api/[controller]")] public class BusinessController : Controller { private readonly IAccountService _accountService; private readonly IPublishService _publishService; private readonly IUnitOfWork _unitOfWork; public BusinessController( IPublishService publishService, IAccountService accountService, IUnitOfWork unitOfWork) { _accountService = accountService; _publishService = publishService; _unitOfWork = unitOfWork; } //这里写具体的WebAPI的Action方法,方法中可以调用各种Service中的业务逻辑方法，然后在方法的末尾，加上_unitOfWork.Commit()即可 }
WebAPI作为整个项目的应用服务层、自身没有任何业务逻辑，而是组合业务逻辑层中的各种Service，完成具体的现实的用户使用需求。
比如一个现实需求是“一个作家，注册成为了作协会员，并登记了他的出版作品”。这个需求可以拆解为两个业务逻辑：1.注册 2.登记出版物 。我们在领域层中实现了这两个业务逻辑后，就可以在应用访问层（我们的Controller中）进行组合、并在同一个事务过程中控制他们了。有人可能会问：你这么做，有什么必要呢，我直接三层架构那样，Controller调用业务逻辑层BLL中的一个“注册并登记出版物”方法，然后这个BLL方法直接去调用DAL中各种数据库操作方法，不也可以实现你所说的吗？
好，这时候，应用服务层+UnitOfWork模式的优点就可以体现出来了。如果是按照传统三层那样，一个BLL方法“注册并登记出版物”，他就只能用于“注册并登记出版物”了，无法实现业务逻辑的组合复用。而使用DDD提倡的编程模式，就可以实现多种业务逻辑组合复用，比如我前面距离的“注册”“登记出版物”这两个领域服务方法，同时还可以组合其他业务逻辑实现更多不同的现实需求中，比如“注册”+“缴费”、“登记出版物”+“领取津贴”，这里每一个需求都是在同一个事务内的，也可以保证数据的一致性。
贴一个IService方法和Service，都在领域层中
public interface IPublishService { void PublishNewBook(Book book); } public class PublishService : IPublishService { private readonly IBookRepository _bookRepository; public PublishService(IBookRepository bookRepository) { _bookRepository = bookRepository; } public void PublishNewBook(Book book) { _bookRepository.Insert(book); } }
贴一个IRepository（领域层中）和它的对应实现（Repository）
//领域层中的Book仓储接口，这里简单起见，没有使用更多的接口方法 public interface IBookRepository:IRepository<Book> { } //基础设施层中使用Dapper操作数据库的实现 public abstract class BaseRepository { private readonly IDbTransaction _dbTransaction; protected internal IDbConnection DbConnection { get; } protected BaseRepository(IUnitOfWork unitOfWork) { _dbTransaction = (unitOfWork.VirtualTransaction) as IDbTransaction; DbConnection = _dbTransaction.Connection; } public CommandDefinition GenCmd(string cmdText, object paramObj) { CommandDefinition cmd = new CommandDefinition(cmdText, paramObj, _dbTransaction); return cmd; } } public class BookRepository :BaseRepository, IBookRepository { public BookRepository(IUnitOfWork unitOfWork):base(unitOfWork) { } //这里只写了Insert方法，其他的可类比 public int Insert(Book t) { string cmdText = "INSERT INTO Book (Id,BookName,Author,Price,PublishTime) VALUES (@Id,@BookName,@Author,@Price,@PublishTime)"; var cmd = GenCmd(cmdText, t);
var result = DbConnection.Execute(cmd); return result; } } //另外一个基础设施层项目中，使用EF操作数据库的实现 public abstract class BaseRepository { protected internal DbContext DbContext { get; } protected BaseRepository(IUnitOfWork unitOfWork) { DbContext = unitOfWork.VirtualTransaction as DbContext; } } public class BookRepository : BaseRepository ,IBookRepository { public BookRepository(IUnitOfWork unitOfWork):base(unitOfWork) { } //这里只写了Inert方法，其他的可以类比实现 public int Insert(Book t) { DbContext.Book.Add(t);
//这里不能写DbContext.SaveChanges(),因为EF的SaveChanges()是一个对所有更改的事务性提交,而根据我们的设计事务不在此处提交，而是在应用服务层的Controller中 return 1; } }
然后，我们就可以在Controller中组合不同Service提供的业务逻辑了，并且可以在同一个事务内，有效的提高了业务逻辑层的复用程度同时保证了同一个Http请求内数据的事务一致性。
标签：enc 引用 es2017 abs blank 逻辑 更换 编程 属性
原文地址：http://www.cnblogs.com/riverflow/p/7835445.html
