一、说明

在SimpleAdmin1.0版本中，我将整体项目结构分为三大块，分别为架构核心、业务模块和应用服务。随着1.0版本的封版，回去再看我之前的项目架构，也暴露了一些问题，比如在1.0版本中，Signalr和Mqtt只能二选一，这显然是不科学的，因为这两种虽然都可以作为消息通知，但是显然可以有更多的应用场景，所以如果两者只能用其一的话，显然整个项目架构就不灵活了。并且随着功能越来越多，太多的代码集合在一个应用中，仅仅以文件夹区分功能模块的话，会不会导致项目越来越臃肿？慢慢的就成了屎山了。这个时候我就想到了很多系统都会采用的插件式开发的模式，在业务模块中，除了基础的功能之外，一些拓展性功能采用插件的方式创建在独立的类库中，这样的话我们想要用哪个功能就引用该功能的项目，如果功能有问题我们也能快速定位到代码的位置，非常方便。于是，我就在SimpleAdmin1.0的基础上，对现有架构进行重新设计，以下是2.0架构设计的一些特色：

  1. 插件式开发：分层明确，减少代码耦合性，增强代码可读性，避免项目成为屎山。
  2. Signalr和Mqtt并存：将Mqtt和Signalr都封装成插件使用，想要使用哪个就引用那个插件，并且支持同时引用。
  3. 支持MemerCache：支持内存缓存，无需依赖redis即可启动项目。

二、项目结构

2.0的项目结构主要分为架构核心、系统插件、业务模块和应用服务,相比于1.0，多了一个插件层。

如图所示：

项目架构合理化建议 项目架构设计_数据库

三、分层说明

3.1 架构核心

SimpleAdmin.Core->核心层

核心层,公共组件,常量,枚举,通用方法等其他核心代码，可以被任何项目引用，不依赖其他项目。

│  Core.Development.json  -->  开发环境配置
│  Core.Production.json  -->  生产环境配置
│  Startup.cs  -->  启动类
├─Attributes  -->  特性
├─BaseInput  -->  共用输入参数(分页,ID传参等)
├─Components  -->  公共组件
├─Const  -->  常量
├─Dto  -->  数据类
├─Extension  -->  拓展
├─UnifyResult  -->  统一返回结果
└─Utils  -->  工具类(验证码,图片处理,种子数据处理等)

3.2 系统插件

系统插件是新增的一层，目的是把一些通用的代码抽取出来，封装成类库插件的形式，给不同的项目引用,如果需要哪个功能，直接引用对应的插件即可，非常清晰。哪个功能有问题直接去对应的插件查找，非常方便。这里不做过多的介绍，后面将单开一篇教程详细介绍插件功能。

3.2.1 核心插件

核心插件通常放置一些系统通用插件，如orm，缓存等，这些是系统的基础，基本上所有业务模块都需要用到的插件。

├─SimpleAdmin.Plugin.Aop  -->  Aop插件
├─SimpleAdmin.Plugin.Cache  -->  缓存插件
├─SimpleAdmin.Plugin.CodeFirst  -->  CodeFirst数据库初始化插件
├─SimpleAdmin.Plugin.Core  -->  插件核心,被其他插件引用
├─SimpleAdmin.Plugin.SqlSugar  -->  SqlSugar ORM插件

3.2.2 系统模块插件

系统模块插件主要是对应的我们SimpleAdmin.System层所用到的插件。

├─SimpleAdmin.Plugin.Batch  -->  批量编辑插件
├─SimpleAdmin.Plugin.Gen  -->  代码生成器插件
├─SimpleAdmin.Plugin.ImportExport  -->  批量导入导出插件
├─SimpleAdmin.Plugin.Mqtt  -->  MQTT插件
├─SimpleAdmin.Plugin.Signalr  -->  Signalr插件

3.3 业务模块

SimpleAdmin.System->系统应用层

系统应用层，主要是提供系统应用服务给Api接口层调用，SimpleAdmin的主要功能都由该层实现。

│  Startup.cs  --> 启动类
│  System.Development.json  -->  开发环境配置
│  System.Production.json  -->  生产环境配置
├─EventSubscriber  -->  事件总线
├─Oss  -->  对象存储
├─Services  -->  服务(系统功能接口加实现)
└─UserManager  -->  用户中心(获取当前请求用户信息)

SimpleAdmin.Application->业务应用层

业务应用层，主要是业务代码的编写，可以将自己的业务写在该层，当然也可以自己新建一层写。本系统该层主要是用作数据权限示例。

│  Application.Development.json  --> 开发环境配置
│  Application.Production.json  --> 生产环境配置
│  Startup.cs  --> 启动类
└─Service  --> 服务(业务功能实现）

3.4 应用服务

3.4.1 Web

SimpleAdmin.Web.Entry->启动层

Web 入口层,主要作用就是作为程序入口,没有什么实际业务，没啥好讲的，主要是一些全局的设置，详情见appsettings.json

│-- appsettings.json --> 启动层配置文件
│-- ip2region.db --> 解析ip用的数据库文件
│-- Program.cs --> 启动类

SimpleAdmin.Web.Core->WebApi接口层

Api接口层,存放web应用所需要用到的代码，如组件，控制器，中间件，过滤器等。

│  Startup.cs  --> 启动类
│  Web.Development.json  --> 开发环境配置
│  Web.Production.json  -->  生产环境配置
├─Components  --> 存放Web组件
├─Controllers --> 存放控制器
├─Filter  --> 过滤器
├─Handlers  -->  处理器
└─Logging  -->  操作日志功能
└─Options  -->  配置文件转实体选项类

3.4.2 后台服务

SimpleAdmin.Background->后台服务层

后台服务层，作为定时任务,MQTT或其他服务载体常驻于后台，不依赖于Web，不会因web服务升级而停止。这样做的好处就是不会被iis内存回收，也不会因为web服务升级而停止工作。

│  Background.Development.json  --> 开发环境配置
│  Background.Production.json  --> 生产环境配置
│  MqttWorker.cs  --> mqtt后台任务
│  Program.cs  -->  启动类
├─Dto  -->  数据转换类

四、总结

SimpleAdmin2.0的架构在1.0的基础上进行了很大的调整，回头再看1.0的代码确实有点屎山那味了，还好在1.0完成之后并没有急着开发新的功能而是重新梳理代码逻辑，优化架构，为以后的新功能开发打好基础，这对我自己来说也是一种进步。在日常工作中也一样，如果你回头看几个月之前写的代码发现可以以更好的方式实现时，说明你的代码水平已经进步了。或许在不久的将来，2.0的架构设计也会被推翻重新设计也说不定🤭，希望能和使用SimpleAdmin开发的coder们一起进步。