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