MVC分層架構是怎么樣的

這篇文章給大家分享的是有關MVC分層架構是怎么樣的的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

傳統MVC三層架構

通常，我們習慣的業務建模方式是圍繞數據表的，先根據業務需要設計數據庫，再完成業務流程的開發。

在實現層面采用MVC分層框架，業務數據在3個層級之間流動（數據的流動性本質）。

雖然采用了MVC分層設計，但是在業務流程實現上仍舊是面向過程式，通常遵循這樣的開發模式：取數據 -> 處理數據 -> 存儲數據，是一種以數據為中心的過程式思想。

大家可以思考一下，你是不是也是這樣開發業務的？

領域驅動設計（DDD）

該理論提出了一種新的分層模式，核心是強調面向對象。

interfaces是表現層，仍舊負責數據渲染，比如渲染頁面，渲染json等等。

domain是領域層，是指具體的某一類實體與操作的類封裝，比如訂單與訂單相關的操作。

application是應用層，組裝多個domain，組成一個具體的業務流程，比如交易下單流程，可能需要調用訂單、用戶、反作弊等等domain。

對于訂單來說，我們傳統MVC通常只把它當做數據庫記錄，是一個”貧血模型”，里面只有訂單的各個屬性列，通過調用model層從數據庫獲取。同時，我們會寫一個service層，封裝對訂單記錄的業務操作方法，即過程式的面向數據的開發模式。

而DDD則不同，它強調訂單是一類實體，具體某一條訂單則對應一個訂單對象。訂單對象具有自己的業務處理方法，數據和方法是封裝在一起的。

此時，如果創建訂單需要獲取用戶信息，那么就需要application層來做組裝：先獲取用戶對象，再調用訂單對象的方法傳入用戶對象來完成下單的一個流程。

application就是來做具體業務流程的一層，進行多個domain的組裝。

MVC與DDD的結合

沒有銀彈，多參考不同的思想，目標是如何優化業務設計與定制高效的開發規范。

我感覺DDD本質就是讓屬于不同領域的功能內聚，然后在應用層組裝不同領域的功能即可。

而反觀我們面向數據的思考方式，很容易做出這樣的事情：為了實現一個跨領域的業務流程，直接將多種不同領域的業務邏輯實現在一起，即把分屬于不同領域的邏輯一股腦的丟在應用邏輯層實現，導致了設計越來越混亂，復用性越來越低。

其實我們也不必完全參考DDD直接改造成面向對象的領域設計，畢竟團隊擅長的建模方式仍舊是圍繞數據的，而不是圍繞領域對象的。

我們完全可以借助DDD來優化MVC分層設計，也就是以領域的眼光來優化MVC的使用。

之前在百度的時候，公司推廣PHP Yaf框架的開發規范就提到很重要的一點，即遵循如下的分層設計：

• view

• controller

• page

• service

• model

結合DDD，我們來重新設計一下每一層要做的事情：

• model：特定領域數據的數據讀寫，比如 訂單領域：

• 一般來說，訂單分為主表和擴展表，兩張表完整表達了訂單業務，所以我會把它倆作為一個model實現。

• service：該層與model層一一對應，說白了將model視作領域的數據部分（純數據），service視作領域的方法部分，共同組成了類似DDD中的實體，只不過我們仍舊是面向數據和過程的實現。

• page：與DDD的application層對應，組裝多個service構成業務流程，向controller返回結果。

• controller：解析請求，組裝參數，調用page完成業務流程，將page返回值進一步加工成view需要的具體樣子。

• view：直接渲染html或者Json等，不應該包含其他的數據處理邏輯。

總結我的想法，service+model應該配對出現，page組裝多個service完成業務流程，controller只是page與view之間的協調者（不應該有任何業務邏輯），

另外，service+model應該按領域思想劃分，而不是按數據表劃分，這樣可以解決大多數的聯表需求。

對于事務需求，應該在application層控制事務開關，依舊組裝多個service完成事務內操作，保證不同領域的邊界清晰。

感謝各位的閱讀！關于“MVC分層架構是怎么樣的”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！