Asp.Net Core工作单元UnitOfWork数据访问模式

一、开篇叙谈

有些同学可能会说我现在的项目毫无项目架构可言，是真的吗？为什么会出现这种疑问。

项目架构这个东西是不断的根据自己的实际业务来演变过来的，在这个前辈们探索的过程中，因此慢慢的提炼别总结出了一些经验(也就是设计思想)，最后就形成了架构模式吧。

一切事物存在即合理，所以你的项目一定是有架构可言的，只是当前的这个架构可能无法更好的满足你业务要求了，你需要进行演变升级了哦。

二、何为项目架构分层

系统架构分层和项目架构分层的区别？

这两个从字面意思很容易混淆，但是这两个概念的确是两码事，希望大家能否分的清楚。

• 系统架构分层：站的角度是硬件（物理）层面（反向代理，正向代理，第三方中间件）。

• 项目架构分层：站的角度是软件（逻辑）层面（Code代码层面）。

三、经典的三层架构(3-Layer)优缺点

• 优点：分层简单，容易上手，是code monkey猴子都容易上手。

• 缺点：大量重复性的CRUD代码。

阿笨经常说的一句话：erverything is price 

一个新的东西的引入虽然解决了上一个存在的问题，但是也是有代价了，将会产生出新的问题。

 

顾名思义，三层架构分为三层，分别是“数据访问层”、“业务逻辑层”、“表示层”。

• 数据访问层(DAL)：实现对数据库中数据的读取和保存操作。

• 业务逻辑层(BLL)：它是DAL和UI层的连接桥梁.既然称作业务层,必然有他的用处,不仅仅是一个中转的功能。

阿笨给大家的建议要记住UI层面上的逻辑可以放在UI层，业务层面上的逻辑建议还是规范一点放在业务逻辑层。

业务逻辑层BLL到底有什么用? 
https://www.cnblogs.com/Garden-blog/archive/2011/04/12/2013268.html

• 表示层(UI)：主要功能是显示数据和接受传输用户的数据，例如Windows窗体和Web页面。

三、Repository仓储模式优缺点

1）、什么是仓储(Repository)是什么？

Repository;中文翻译为仓库，大家都知道仓库里面装了很多各种各样的东西，那么你需要东西只要从仓库里面拿去就可以了，你不用关系仓库里面的东西存放在具体的那个位置上。调用方不要问，也不需要知道，你只负责从里面拿(获取)即可。

一般结合ORM框架，比如EF，Dapper等等。因为这类的框架天生就具备了高度复用的CRUD特性功能。

• 优点：

1、CRUD达到了复用目的（把一些公共的调用数据库的方法剥离出来，减少冗余的代码）。

2、为业务开发（程序开发）提供统一的规范。大家编码都规范了，都按照标准的作业模式让仓库中放存放(编写代码)自己的东西了，用到的时候大家都可以互相借用（共用）。

• 缺点：    

1）、多个Repository之间怎么保存在一个事务单元内的操作？

三、UnitOfWork工作单元模式

1. 什么叫工作单元？

跨多个请求的业务，统一管理事务，统一提交。

2. 为什么要工作单元？

 我们经常的代码都是分层的，有可能到处都在 new DbContext(options)，这是就要面对如何管理这些DbContext，在AspNetCore中 services.AddDbContext<>默认是用的Scope的作用域，也就是每次HttpRequest，比以前好了很多。但是事务这些管理还是很麻烦。

 

 

 如上图 有一个Action需要调用很多Service 然后 Service之间又相互调用，在开启Action时 其实是想开启一个事务，但是某些内部代码有可能自己去开启了事务。相互之间调用管理起来非常麻烦。经常出现不可估计的问题。如果有一个集中管理的地方就好很多。比如在Action这里启动一个工作单元，后续所有的业务都使用同一个事务 和 DbContext，这才是我们的预期的。

3. 如何使用工作单元？

http://www.aspnetboilerplate.com/Pages/Documents/Unit-Of-Work

只需要记住一点：当 Unit Of Work 中的 Commit() 方法执行时，所有仓库Repository中发生在对象上的修改都将提交到数据库中。