4.分層規範實踐
4.0命名規範遵循：
簡單、可讀、優雅
4.1表現層規範
（1）項目命名規則：
如果是API服務，則命名規則爲：{公司}.{業務名}.API 比如：Com.Channel.API
如果是MVC站點，則命名規則爲：{公司}.{業務名}.MVCSite 比如：Com.Channel.MVCSite
4.2邏輯層規範
（1）項目命名規則：{公司}.{業務名}.Business
比如：Com.Channel.Business
（2）類名以Logic結尾
4.3數據層規範
（1）項目命名規則：{公司}.{業務名}.{數據庫}DB
比如：Com.Channel.MSSQLDB
（2）約定在應用中使用SQL語句，不使用存儲過程。舊的存儲過程可以繼續使用和修改。
（3）使用數據庫的最新特性進行分頁
4.4實體層規範
DTO規範
（1）項目命名規則：{公司}.{業務名}.DTO
比如：Com.Channel.DTO
（2）請求參數DTO實體類放在Request文件夾下,且命名規則爲以Request結尾，如下圖的 SearchColorRequest.cs
（3）響應DTO實體類放在Response文件夾下，且命名規則爲以Response結尾，如下圖的 SearchColorResponse.cs
（4）如果請求或響應的DTO實體類的屬性中有對象或枚舉，那麼這些對象所屬的類、枚舉放在DTO項目的Common文件夾下。
（5）如果請求或響應的DTO實體類有基類要繼承，那麼約定爲基類取名爲RequestBase.cs、 ResponseBase.cs，且這些基類直接放在DTO項目的Common文件夾下。
VO規範
（1）項目命名規則：{公司}.{業務名}.ViewModel 比如：Com.Channel.ViewModel
（2）VO實體類約定用Controller作爲文件夾名稱
（3）VO實體類名的命名約定:
請求VO以Input/Form/Query結尾,如下圖的Colorlnput.cs 響應VO以Output/List/Result結尾,如下圖的ColorOutput.cs
4.5公共層規範
（1）項目命名規則：{公司}.{業務名}.Util
比如：Com.Channel.Util
4.6測試層規範
（1）項目命名規則：{公司}.{業務名}.UnitTest
比如：Com.Channel.UnitTest
（3）測試方法命名約定
測試方法名分成三段：主題+期望結果+參數
4.6參數校驗層規範
我們知道參數校驗對整個系統的安全性和性能來說是很重要的一個環節。
那麼我們的參數校驗應該怎麼做才能讓自己滿意呢？ 也就是說怎樣才能讓到處都存在的參數校驗變得優雅呢？
因爲參數校驗屬於非業務性代碼，所以我的想法是使用AOP把他切割出來，不能讓校驗代碼和業務邏輯耦合，而且散落在各處，爲此我把校驗類獨立出來，如下圖所示：
在Controller層的做法也很簡單，就是綁定一下即可，如下圖所示：
5.其他規範
（1）配置文件分開發環境和生產環境
5.1DB配置規範
（2）數據庫連接的配置讀寫分離，鏈接字符串加密處理
（3）數據庫連接配置名的命名規則:{業務}_DB_CONN_讀寫類型(如上圖所示)
5.2配置文件規範
（1）統一使用json文件的配置方式
（2）json文件的讀取
- 映射對象
- 統一走AppSetting封裝類，通過冒號（：）進行讀取
- 數據庫做讀寫分離
5.3靜態資源文件規範
（1）公共的靜態資源文件(CSS、JS、Image等)放在另外的靜態站點中，統一由前端進行開發和維護。一般CSS文件放在css文件夾下，JS文件放在js文件夾下， Image圖片文件放在img文件夾下，如下圖的左半部分所示。（截圖說明，如下圖所示：）
（2）靜態資源文件必須使用版本號管理，以免更新後由於客戶端瀏覽器緩存而導致站點使用的依然是舊版本的靜態資源文件:
<script src="~/js/order.js?v=(Appsetting.StaticFileVersion"></script>
（3）採用前後端完全分離的方式，讓Java或NET開發資源撤出表現層，以專注於業務邏輯需求的迭代。
運行，您下載後，所要做的工作就是運行，然後就看到Swagger了(如下圖所示)
框架後續
版本系列:
- 單體敏捷框架
- AF3(Agile Framework3)，基於三層邏輯概念劃分；
- AFD(Agile Framework DDD)，基於DDD驅動設計原理劃分；
- 微服務敏捷框架
- AMFS(Agile Microservice Framework Single Repository)，基於單體代碼倉庫劃分；
- AMFM(Agile Microservice Framework Muti-Repository)，基於代碼多倉庫劃分；