web后端開發的同學對MVC模型應該都不陌生，但隨著項目復雜度的增加，MVC模型的不合理使用會讓項目逐漸失控。接下來我們來探討一下如何把項目的復雜度維持在可控范圍。
首先，MVC模型本身沒什么問題，它所提供的只是一種思路而已。通常情況下我們會把ORM的代碼寫到Model里面，處理HTTP請求的邏輯寫到Controller里面，而返回的數據如HTML/JOSN邏輯則會寫到View里面。看起來沒啥問題，那么我們的代碼是怎么一步步變得臃腫混亂的呢？
起初，業務還很單純，一個HTTP請求打過來，通過路由找到對應的 Controller 方法，順帶解析出了請求參數，接著把參數直接交給Model進行CURD，然后從Model構建View所需要的參數，最后把View的輸出作為Controller的響應數據。后來，業務沒那么單純了，Controller拿到數據后，不只要進行簡單驗證，還要去數據庫查數據，檢查，然后再決定是不是要進行下一步處理，慢慢地Controller里面開始堆積大量數據庫操作即Model層的調用代碼，與此同時，View層開始有更多的展示需求，往往一個頁面需要好幾個Model的數據，而且彼此間往往存在邏輯關系，漸漸地View里面也有了很多直接對Model的操作代碼。同樣的，在Model層，一個業務的流程通常是要涉及到多個表單的處理，所以往往有些Model有很多其他Model的操作代碼和數據格式轉換方法。而且隨著項目的演進，這種情況會越來越嚴重。邊界不清晰導致了代碼組織的換亂。
在面相對象的編碼模式中，重要的是模塊與模塊之間的溝通而不是類本身。
對于Model層的理解偏差導致我們忽略了定義邊界：
Controller 作為HTTP的直接服務者，它的任務就是解析HTTP參數，調用合適業務邏輯服務，根據該服務的響應，選擇合適View服務以構建HTTP響應數據。Controller的邊界是對HTTP協議而言，所以其 ControllerModel 應該按照HTTP標準制定。
Model 層應該改名叫數據存儲層，與數據庫交互的層應該叫做 StoreModel，他所要關心的只是如何與數據庫進行交互。在此之上應該有更高層次的業務層，以業務線為單位的數據庫操作組合。業務對外的邊界要形成自己的一套標準，即將請求參數和返回信息的規范化，尤其要注意的是定義好業務層的錯誤與異常的分類，以便服務使用者做相應的處理。
View 層也是同樣的道理，需要一個ViewModel層來處理請求參數并構建模板文件需要的結構體，模板文件只是View層的最后環節，不應該直接與Model層進行交互。
以上。
