基於.NET6的簡單三層管理系統

前言

筆者前段時間搬磚的時候，有了一個偷懶的想法：如果開發的時候，簡單的CURD可以由程式碼生成器完成，相應的實體、服務都不需要再做額外的註冊，這樣開發人員可以省了很多事。

於是就開了這個專案，期望實現這樣的能力：業務人員只需關注實體的構建，業務服務的編寫，以及路由的設定。

讓業務的開發，變成簡單的三步走：建立實體 >> 業務開發 >> 路由設定。

目前專案構思的絕大部分能力已完成（程式碼生成器、定時任務還未實現），現將專案發布，希望能對搬磚的大傢伙有所幫助。

專案概述

前後端分離，使用 JWT 認證。

後端：基於 .NET6 和 EF Core，整合常用元件，採用傳統三層結構。

前端：基於 小諾1.8 做適配，主技術棧：Vue2.6.x、Ant-Design-Vue

體驗地址

http://175.178.244.200:12060/

管理員：superAdmin 密碼：123456

普通使用者：user 密碼：123456

快速開始

請參考專案檔案：使用手冊

參考專案

注：排名不分先後。

小諾 snowy

Admin.NET

Blog.Core

Adnc

Furion

ABP

感謝這些優秀的開源專案！

基本設計思路

• 依賴於抽象

  依賴倒置原則，控制反轉（IoC）

• 切面程式設計（AOP）

  許可權、紀錄檔、異常等通過過濾器（Filter）或中介軟體（Middleware）等實現，集中程式設計

• 可設定

• 自動註冊

  自動註冊實體（Entity）、自動註冊服務類（Service）等

專案結構

專案結構構思

主要分為三層：Interface表現層、Services服務層、Repository倉儲層

Interface：Host依賴所有層，完成程式設定（如：Program.cs 中DI容器注入服務，中介軟體管道設定等）；Web API 設定路由，提供 API 介面，如果程式以後有遷移、或替換前端的情況，也可以在這裡做一層介面卡（注：API只是一種表現形式，也可以為MVC）

Services：所有的業務都在這一層。從倉儲中讀取資料模型（Models），進行業務操作，返回DTO（Data transfer objects）給表現層。

Repository：資料庫存取。

通用的模組：Model、Common、Framework

Models：包含所有資料模型，如 Entity（物件資料庫的資料表）、CacheItem快取物件、EventModel事件模型等。

Common：整合常用元件，根據專案需要做相應設定；提供基礎服務，如CurrentUser存取當前使用者資訊；提供靜態幫助類，所有無狀態的函數都歸入此類，如GuidHelper.Next() 產生連續 Guid。

Framework：框架，比如參照ABP或Furion等框架，甚至是自己專案一些通用的能力，可以到處用的。

實際專案結構

實際上，把 IServices 和 IRepository 此類介面層幹掉了。

Models 則歸入了對應的使用者裡面，Framework 也沒有。

Common        # 基礎設施：整合常用元件；提供基礎服務；提供靜態幫助類
Repository    # 倉儲層：資料庫存取，資料庫遷移
Services      # 服務層：業務實現
WebApi        # 表現層：完成程式設定；設定路由，提供API介面

目錄結構如下，更詳細的結構，請檢視檔案。

├─config                  # 一些組態檔，如：redis 的組態檔
├─doc                     # 專案檔案
├─web                     # 前端
├─webapi                  # 後端
   ├─Simple.Common        # 基礎設施
   ├─Simple.Repository    # 倉儲層
   ├─Simple.Services      # 服務層
   └─Simple.WebApi        # 表現層

業務能力

• 組織架構
  • 組織機構（organization）
  • 崗位（position）
  • 使用者（user）
• 許可權管理
  • 應用（application）
  • 選單（menu）
  • 角色（role）
• 開發管理
  • 資料字典（dictionary、dictionaryItem）
• 紀錄檔管理
  • 操作紀錄檔（log operating）
  • 異常紀錄檔（log exception）

系統能力

• 認證：整合Cookies、JWT；預設啟用 JWT
• 授權：基於策略（Policy）的授權
• ORM：EF Core 的 Code First 模式
• 依賴注入：預設 DI 容器，實現自動注入
• 快取：IDistributedCache，預設注入 Memory Cache，可替換 Redis
• 紀錄檔：NLog
• 事件匯流排：預設啟用 BackgroupService，基於Channel 實現的單機版釋出訂閱；可替換為 Redis 的釋出訂閱（可用於分散式）；也可替換為 RabbitMQ 的釋出訂閱（可用於分散式）
• 定時任務：Quartz
• 資料驗證：模型驗證（Model validation）
• 物件對映：AutoMapper

專案亮點

• EF Core 自動遷移指令碼

一些Q&A

為什麼把 IServices 這些介面層給幹掉了，僅留下實現層？

答：一般專案中會如有 IRepository 和 IServices 這些個抽象層，主要是為了控制反轉（IoC），實現專案各層之間解耦，最終目的就是為了「高內聚，低耦合」。

筆者認為，對於單體專案來說，做到高內聚即可，再追求完全的低耦合，會增加成本和困擾（舉個簡單的栗子：專案初期，業務大改是常有的事，改服務類的介面的事並不少見。除非說業務主體明確，需要修改的，並不是業務的介面，而是業務的具體實現）。

最後是這個專案，本就是為了追求最簡三層單體。

為什麼不對倉儲額外封裝一層？

答：簡單的專案基本上是單資料庫的，且 EF Core 已經實現了工作單元和倉儲模式，可以不用再封裝一層。

當然，筆者還是建議跟ABP框架那樣再封裝一層倉儲，可以避免一些後續的開發運維問題（比如：系統遷移、重構等）。

原始碼

Gitee：https://gitee.com/lisheng741/simpleapp

Github：https://github.com/lisheng741/SimpleApp