为什么recall,因为之前有个task涉及到项目的配置问题,完全不知道配置文件到底在干什么,重新结合 ABP的模块化理解一下。
之前对模块化的理解:结合ABP VNext来理解DDD_abp.vnext和abp哪个生产ddd_董厂长的博客-CSDN博客
再深入一些:为了柔性部署(包括独立部署,也可集成部署)
- 原子封装,高度内聚——从设计原则看职责相对单一独立
- 功能独立,职责单一——从设计原则看摆脱了耦合的风险
- 随意组合,按需装配——从扩展来看十分灵活,容易维护
- 独立开发,独立部署——从任务分解来看,分工非常容易
- 面向接口,遵循约定——从框架设计来看,功底深厚
- 极少修改,能力复用——从业务角度看,极大提高开发效率
最能体会的应该是独立开发独立部署。
code example:
ABP项目中的
program.cs
文件是一个C#控制台应用程序的入口点。它包含一个静态的Main
方法,该方法是应用程序的起始点。在ABP框架中,program.cs
文件通常用于启动Web应用程序或后台服务。它可以配置应用程序的依赖注入容器、日志记录、数据库上下文等,并启动应用程序的主机。通过编辑program.cs
文件,可以自定义应用程序的启动过程和配置。
随着项目的增长,配置文件下可能会增加很多配置
第一种想法,把相关的一系列配置抽象为静态方法,例如将所有swagger相关配置放到一个静态方法里面,想用的时候就调用。
缺点:需要注意 A配置可能在B配置之后,需要关注配置顺序。
进一步,抽成一个类库。项目A需要就引用绿色类库,项目B需要也可以引用绿色类库的方法。
缺点没变:需要关注配置顺序。
ABP的做法:
这两个方法和之前的静态方法的改造是一样的道理。给了两个拓展方法
把之前的demo改成拓展方法的形式,看上去就像ABP的progrma.cs:
简单理解是:接管了这个builder
再改造一下之前的demo: