本來打算將搭建項目架構和集成SqlSugar放在一起講的，但是感覺東西有點多，還是分成兩章吧~

這一章講搭建項目的整體架構，這裏先把搭建完成後的最終效果放出來，然後再逐個解釋每層的作用。

可以看到這裏一共有七層，源碼在最下面，需要的可以參考源碼進行對比（下面我按照自頂層向底層的順序介紹，所以列出的順序和圖片有點區別）

（一）RayPI主項目層

我在控制器文件夾下添加了兩個文件夾，Admin和Client，分別用來存放後臺和前端的接口。

這麽做主要有兩個理由，一個是我覺得這樣可以把後臺和前臺的功能、權限分的清楚些；第二個是，後面我們要試著讓我們的框架可以自動生成一些必備的代碼，以減少重復的工作量。這些代碼主要就是增刪改查的功能，我會將它們自動生成到admin裏（畢竟對後臺來說，每個實體都會涉及到增刪改查，這是跑不了的）。

控制器層除了偶爾會做一些參數是否為空的驗證外（有人連驗證也不在控制器層做），其他不做任何操作，只是將參數傳給業務邏輯層處理（下面一個講）。

所以除了接口的註釋信息、接口路徑、方法和權限設置外，這一層就不應該有其他任何亂糟糟的代碼了~

（二）RayPI.Bussiness業務邏輯層

我在業務邏輯層也就分成了Admin和Client兩塊，分別用來處理前後臺的業務邏輯。該層只做業務邏輯的相關運算，不會對數據庫進行任何直接的操作。

業務邏輯層接收到控制器層傳遞的參數後，將這些參數做相應的處理，然後將加工後的參數床給下一層：數據接口層。（按照比較的三層架構思想，其實應該傳給數據層，但是這裏利用數據接口層做了一個分隔，好處後面慢慢就會發現了）

（三）數據接口層

該層為數據接口層，裏面只羅列了相應的接口函數，但是具體的函數功能實現則交給集成該數據接口的數據層來實現。

這樣做的好處是可以將數據庫操作與代碼邏輯操作分離的更加清晰。不論是編寫代碼還是閱讀代碼，我們在操作業務邏輯層時只需要知道我們調用的數據接口的功能即可，但是這個功能的具體實現則暫時不需要考慮；當我們編寫或閱讀數據層時，只需要考慮是否實現了繼承的接口的功能，而不需要再往上去看業務邏輯層。

（四）RayPI.Service數據層

該層負責直接或者間接對數據庫數據進行操作，如果你是用原生的或者類似Dapper的數據庫數據庫中間件，那麽在這一層就會看到相應的sql語句（當然，這裏我們選擇了集成SqlSugar作為數據庫操作中間件）。

該層繼承了相應的數據接口，所以必須實現接口內的所有函數。

圖片上可以看到還繼承了一個類，叫BaseDB，這個類是我自己添加的幫助類，在下面會講的Model層裏，裏面只有一個函數GetClient，用來返回SqlSugarClient類（這個是SqlSugar集成的類，下一章具體講）。

（五）RayPI.Entity實體層

該層為實體類層，存儲了數據庫對應的所有實體，實體一般和數據庫表是一一對應的。

（六）RayPI.Model模型層

該層存放了一些系統幫助類，或是實體輔助類。

BaseDB用於返回返回SqlSugar的SqlSugarClient類，數據層可以直接繼承該類。

BaseDBConfig用戶存放數據的配置信息，比如書庫連接字符串（這些配置信息還可以分離出來，存放到主項目的json文件中，以供讀取，這個後面專門提出來一章講）。

MessageModel是一個泛型的返回類，用於格式化的向接口返回數據。

TableModel也是一個返回類，用於格式化的向接口返回列表格式的數據。

（七）SqlSugar層

這一層並不是搭建出來的，而是從github引用的源碼。SqlSugar是一個開源的ORM框架，可以實現度數據庫靈活方便的操作。如果你是選擇不引用源碼，而是利用Nuget導包的方式向項目引入，那麽項目裏就沒有這一層。

關於引入並配置SqlSugar下一章再講~

具體的代碼實現可以參考下面的源碼

源碼下載地址：

到目前為止，項目架構相比第一章已經有點模樣了，但是還有很多需求沒有涉及到。

比如後面我們會加入的用於存放我們自己常用靜態函數的RayPI.Helper層、用於設置接口權限的RayPI.Token層、用於集成支付寶微信等第三方支付SDK的RayPI.Pay層等等。

還有比較重要的功能就是，我會嘗試著讓框架實現部分的自動化。比如從後臺自動生成數據庫表（或是在已經有表的情況下自動生成entity實體代碼），按模塊自動生成增刪改查的基礎代碼，自動生成基礎的頁面等等。

今天先這樣吧~

【從零開始搭建自己的.NET Core Api框架】（二）搭建項目的整體架構