web后端開發(fā)的同學(xué)對MVC模型應(yīng)該都不陌生，但隨著項目復(fù)雜度的增加字旭，MVC模型的不合理使用會讓項目逐漸失控崖叫。接下來我們來探討一下如何把項目的復(fù)雜度維持在可控范圍遗淳。
首先，MVC模型本身沒什么問題心傀，它所提供的只是一種思路而已屈暗。通常情況下我們會把ORM的代碼寫到Model里面养叛，處理HTTP請求的邏輯寫到Controller里面宰翅，而返回的數(shù)據(jù)如HTML/JOSN邏輯則會寫到View里面弃甥。看起來沒啥問題汁讼，那么我們的代碼是怎么一步步變得臃腫混亂的呢淆攻？
起初，業(yè)務(wù)還很單純嘿架，一個HTTP請求打過來瓶珊，通過路由找到對應(yīng)的 Controller 方法，順帶解析出了請求參數(shù)耸彪，接著把參數(shù)直接交給Model進(jìn)行CURD伞芹，然后從Model構(gòu)建View所需要的參數(shù)，最后把View的輸出作為Controller的響應(yīng)數(shù)據(jù)搜囱。后來丑瞧，業(yè)務(wù)沒那么單純了，Controller拿到數(shù)據(jù)后蜀肘，不只要進(jìn)行簡單驗證绊汹，還要去數(shù)據(jù)庫查數(shù)據(jù)，檢查扮宠，然后再決定是不是要進(jìn)行下一步處理西乖，慢慢地Controller里面開始堆積大量數(shù)據(jù)庫操作即Model層的調(diào)用代碼狐榔，與此同時，View層開始有更多的展示需求获雕，往往一個頁面需要好幾個Model的數(shù)據(jù)薄腻，而且彼此間往往存在邏輯關(guān)系，漸漸地View里面也有了很多直接對Model的操作代碼届案。同樣的庵楷，在Model層，一個業(yè)務(wù)的流程通常是要涉及到多個表單的處理楣颠，所以往往有些Model有很多其他Model的操作代碼和數(shù)據(jù)格式轉(zhuǎn)換方法尽纽。而且隨著項目的演進(jìn)，這種情況會越來越嚴(yán)重童漩。邊界不清晰導(dǎo)致了代碼組織的換亂弄贿。
在面相對象的編碼模式中，重要的是模塊與模塊之間的溝通而不是類本身矫膨。
對于Model層的理解偏差導(dǎo)致我們忽略了定義邊界：
Controller 作為HTTP的直接服務(wù)者差凹，它的任務(wù)就是解析HTTP參數(shù)，調(diào)用合適業(yè)務(wù)邏輯服務(wù)侧馅，根據(jù)該服務(wù)的響應(yīng)危尿，選擇合適View服務(wù)以構(gòu)建HTTP響應(yīng)數(shù)據(jù)。Controller的邊界是對HTTP協(xié)議而言施禾，所以其 ControllerModel 應(yīng)該按照HTTP標(biāo)準(zhǔn)制定脚线。
Model 層應(yīng)該改名叫數(shù)據(jù)存儲層，與數(shù)據(jù)庫交互的層應(yīng)該叫做 StoreModel弥搞，他所要關(guān)心的只是如何與數(shù)據(jù)庫進(jìn)行交互邮绿。在此之上應(yīng)該有更高層次的業(yè)務(wù)層，以業(yè)務(wù)線為單位的數(shù)據(jù)庫操作組合攀例。業(yè)務(wù)對外的邊界要形成自己的一套標(biāo)準(zhǔn)船逮，即將請求參數(shù)和返回信息的規(guī)范化，尤其要注意的是定義好業(yè)務(wù)層的錯誤與異常的分類粤铭，以便服務(wù)使用者做相應(yīng)的處理挖胃。
View 層也是同樣的道理，需要一個ViewModel層來處理請求參數(shù)并構(gòu)建模板文件需要的結(jié)構(gòu)體梆惯，模板文件只是View層的最后環(huán)節(jié)酱鸭，不應(yīng)該直接與Model層進(jìn)行交互。
以上垛吗。
