一、說明 在SimpleAdmin1.0版本中，我將整體項目結構分為三大塊，分別為架構核心、業務模塊和應用服務。隨著1.0版本的封版，回去再看我之前的項目架構，也暴露了一些問題，比如在1.0版本中，Signalr和Mqtt只能二選一，這顯然是不科學的，因為這兩種雖然都可以作為消息通知，但是顯然可以有 ...
一、說明
在SimpleAdmin1.0版本中，我將整體項目結構分為三大塊，分別為架構核心、業務模塊和應用服務。隨著1.0版本的封版，回去再看我之前的項目架構，也暴露了一些問題，比如在1.0版本中，Signalr和Mqtt只能二選一，這顯然是不科學的，因為這兩種雖然都可以作為消息通知，但是顯然可以有更多的應用場景，所以如果兩者只能用其一的話，顯然整個項目架構就不靈活了。並且隨著功能越來越多，太多的代碼集合在一個應用中，僅僅以文件夾區分功能模塊的話，會不會導致項目越來越臃腫？慢慢的就成了屎山了。這個時候我就想到了很多系統都會採用的插件式開發的模式，在業務模塊中，除了基礎的功能之外，一些拓展性功能採用插件的方式創建在獨立的類庫中，這樣的話我們想要用哪個功能就引用該功能的項目，如果功能有問題我們也能快速定位到代碼的位置，非常方便。於是，我就在SimpleAdmin1.0的基礎上，對現有架構進行重新設計，以下是2.0架構設計的一些特色：
插件式開發：分層明確，減少代碼耦合性，增強代碼可讀性，避免項目成為屎山。Signalr和Mqtt並存：將Mqtt和Signalr都封裝成插件使用，想要使用哪個就引用那個插件，並且支持同時引用。支持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的架構設計也會被推翻重新設計也說不定
