一、开篇叙谈
有些同学可能会说我现在的项目毫无项目架构可言,是真的吗?为什么会出现这种疑问。
项目架构这个东西是不断的根据自己的实际业务来演变过来的,在这个前辈们探索的过程中,因此慢慢的提炼别总结出了一些经验(也就是设计思想),最后就形成了架构模式吧。
一切事物存在即合理,所以你的项目一定是有架构可言的,只是当前的这个架构可能无法更好的满足你业务要求了,你需要进行演变升级了哦。
二、何为项目架构分层
系统架构分层和项目架构分层的区别?
这两个从字面意思很容易混淆,但是这两个概念的确是两码事,希望大家能否分的清楚。
• 系统架构分层:站的角度是硬件(物理)层面(反向代理,正向代理,第三方中间件)。
• 项目架构分层:站的角度是软件(逻辑)层面(Code代码层面)。
三、经典的三层架构(3-Layer)优缺点
• 优点:分层简单,容易上手,是code monkey猴子都容易上手。
• 缺点:大量重复性的CRUD代码。
阿笨经常说的一句话:erverything is price
一个新的东西的引入虽然解决了上一个存在的问题,但是也是有代价了,将会产生出新的问题。
![](https://i-blog.csdnimg.cn/blog_migrate/3fbe13faa9a13e213a687b9f866cd17b.png)
顾名思义,三层架构分为三层,分别是“数据访问层”、“业务逻辑层”、“表示层”。
• 数据访问层(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,比以前好了很多。但是事务这些管理还是很麻烦。
![](https://i-blog.csdnimg.cn/blog_migrate/b1f91157fc5be21f3ce537f69bcfca24.png)
如上图 有一个Action需要调用很多Service 然后 Service之间又相互调用,在开启Action时 其实是想开启一个事务,但是某些内部代码有可能自己去开启了事务。相互之间调用管理起来非常麻烦。经常出现不可估计的问题。如果有一个集中管理的地方就好很多。比如在Action这里启动一个工作单元,后续所有的业务都使用同一个事务 和 DbContext,这才是我们的预期的。
3. 如何使用工作单元?
http://www.aspnetboilerplate.com/Pages/Documents/Unit-Of-Work
只需要记住一点:当 Unit Of Work 中的 Commit() 方法执行时,所有仓库Repository中发生在对象上的修改都将提交到数据库中。