一、前言
都說”不想做架構師的開發不是好前端“，”一千個讀者心中有一千個哈姆雷特“，我相信每個開發者心中，都有一個屬于自己的框架，所以今天我就給大家探討一下我心中的簡單分層架構設計，
在說分層架構設計之前，先說下我對架構設計的理解，不足之處還希望大神指點，《.NET應用架構設計》這本書里面寫到：架構設計其實為“架構”和”設計”的兩個概念，架構是對業務需求的高層抽象，而設計是將高層抽象的需求與具體的技術實作聯系起來，在此程序中，會根據實際情況考慮到系統的穩定性、安全性、擴展性兼容性等各種因素，所以在專案業務需求提出之后，經過架構分析，得到系統的機構方案，然后根據架構方案做不同的設計方案，選擇適合的設計方案進行開發，架構設計和代碼重構一樣，他不是一蹴而就的，他也是在迭代中變得完善和穩定，
說到這里，我想說一下框架和模式，平常中或多或少都會看到xx框架、xx模式，架構設計主要體現在設計上面，他們輸出可能是檔案或者偽代碼等，而框架就是對架構設計的累計實作，比如作業中的專案框架，都是在我們經過多次設計、重構過后，得到公共模塊（也就是我們說的輪子），在這個基礎上，開發就會很便利，模式這是根據開發經驗，提出某些問題比較好的解決方案，比如說單例模式、工廠模式等，
當然架構設計肯定沒有說得這么簡單，他還有很多設計原則和理論，感興趣的朋友可以自己去了解一下，
下面就是蝸牛根據自己的理解，結合到一個例子對多層架構設計和實作，如果有不合理的地方，希望大家都多指點，
二、分層架構設計實作
一說到分層（這里我們說的是邏輯分層），相信很多人都會想到經典的三層架構，其實分層的目的是把功能按照不同的角色分隔開，便于后期系統擴展、維護，所以三層只是一個最少的層次劃分，具體的層次需要根據專案實際的業務情況以及系統的部署情況進行劃分，下面我就以一個專案進行說明，
現在需要實作一個論壇的專案，并發量等非業務因素現在都不做考慮，由于經費原因，只能提供一臺服務器作為部署環境，可以支持PC端和手機端訪問，
我相信很多園友在做專案的時候，都遇到過這個情況，客戶只知道他想要這個東西，但是其他的，他一概沒考慮，由于這個是例子，就直接按照上面的需求做了，細節方面就后面再修改，
2.1、分層約束
2.2、分層描述
界面層：用戶界面或表現層，即MCV中的view層；
界面控制層和API介面層：界面控制層即MCV中的Control層（使用.net的mvc），API介面層主要以Webapi提供介面，主要用于實作輕業務、引數校驗、例外封裝以及權限驗證；
業務邏輯層（Service層）：實作業務處理邏輯；
業務Manager層：可復用邏輯層，完成：1. 對第三方平臺封裝的層，預處理回傳結果及轉化例外資訊；2. 對Service層通用能力的下沉，如cache,mq等通用處理；
資料持久層（Dao層）：資料庫訪問層，
Common層：里面主要包含業務方法庫和公共方法庫，業務方法庫：主要是協助業務邏輯層處理邏輯，即含業務的公共方法，只被業務邏輯層呼叫；公共方法庫：包含公共方法，可以被所有層呼叫，公共方法庫還有一個原則，就是他不依賴Model，他對于任何層次都可以單獨呼叫，以后作為框架的一個公共庫模塊，這也就是為什么還會存在一個業務方法庫，
分層說明：因為界面層使用的MVC，所以對應的就有界面控制層，如果前后端分離，就只需要API介面層即可，
2.3、分層模型描述
Entity：主要是對資料庫表結構一一對應；
DTO：資料傳輸型別總稱，這里將他作為一個象征名詞，具體分為：Request（請求物件），Response（回應物件）和DTO（資料傳輸物件），
模型運用場景：
界面層發送Request引數請求，界面控制層將請求分發到對應的Service層，Service層根據業務拆分成不同的DTO引數請求或者不做拆分，再發送到Dao層，Dao層訪問資料庫，如果是資料庫表查詢，回傳Entity物件，如果是多表業務查詢，回傳DTO物件，Service層經過業務處理回傳Response物件到界面控制層，界面層直接回傳Response物件，由于專案較小，回傳程序中的Entity物件和DTO物件也可以直接回傳，
2.4、實作技術
前端技術：html5,css3,javascript,jquery,layui以及它的fly論壇界面;
后端技術：采用.net MVC、WabAPI以及.net Framework為目標框架；類別庫采用standard作為目標框架；ORM使用Dapper；依賴注入采用Unity；日志框架使用Log4Net;
技術選型說明：界面層和界面控制層選用的是.net Framework為目標框架的.net MVC，而.net Core是以后的大勢，所以剩下的類別庫都選用standard作為目標框架，后面如果使用.Net Core進行跨平臺，直接替換界面層和界面控制層即可，在研發程序中還會添加其他的技術，所以架構設計也要不斷的迭代，
2.5、編碼規范
這里的規范只對架構方面的規范，至于代碼書寫的規范（命名，注釋等）就不做描述了，
1、命名規范
業務邏輯層（Service層）所有檔案必須以Service結尾；
業務Manager層所有檔案必須以Manage結尾；
資料持久層（Dao層）所有檔案必須以Repository結尾；
Entity物件所有檔案必須以Entity結尾；
界面層發送的請求必須以Request結尾；
回傳給界面層的資料必須以Response結尾；
其余的傳輸的資料物件必須以DTO結尾，
2、依賴注入
業務邏輯層（Service層），業務Manager層，資料持久層（Dao層）必須有對應的介面層，采用依賴注入的方式實體化物件，
3、方法庫
業務方法庫和公共方法庫都必須是靜態方法，并且業務方法庫只能被業務邏輯層（Service層）呼叫，
4、引數規范
所有的方法，請求和回傳物件都必須一一對應，（主要是防止一個物件多用，導致后期混亂不堪）
5、檔案歸類
同一功能或者同一型別方法或者物件，需要用檔案夾同一依賴，
備注：開發程序中還有其他的約定規范，后面不斷的迭代，
2.5、分層架構實作
先創建一個命名為“PFTSnailSystem”的空白解決方案，然后根據分層約束，我們將他們歸納為：CommonLayer、ModelLayer、BusinessLayer、DataLayer和PresentationLayer，為了給他們指定順序，所以在他們前邊加上編號，
如圖：
現在我們就將各層分別創建到指定的檔案中，如圖：
，
注意：創建類別庫一定選擇standard框架，
其中，PFT.Snail.Core為業務方法庫，PFT.Snail.Utility為公共方法庫，其他的專案跟前面分層描述一一對應，并且都有單獨的對應的介面類別庫，
三、總結
到目前為止，我們整理好了架構，架構方案的樣子也在專案中有個輪廓了，雖然也存在著設計，但設計還沒做完，其實對于設計是否完成，也是仁者見仁智者見智，設計可以詳細到具體的UML類圖，前面，我們雖然對每層做了規范限制，也說明了專案的使用的相關技術，但是都說得很抽象，因為設計的結果，就是專案的“規格說明”，而我們現在的都沒有設計到專案需求，這個架構也可以適用到其他專案，所以后面我們將針對不同的功能模塊，先做設計方案，然后撰寫實作設計方案，同時將逐步實作架構里面的基礎功能，
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/16028.html
標籤：ASP.NET
上一篇：SqlHelper
下一篇：ORM之Dapper運用