13518219792
這篇文章給大家分享的是有關MVC分層架構是怎么樣的的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。
創新互聯公司成立十多年來，這條路我們正越走越好，積累了技術與客戶資源，形成了良好的口碑。為客戶提供做網站、成都做網站、網站策劃、網頁設計、國際域名空間、網絡營銷、VI設計、網站改版、漏洞修補等服務。網站是否美觀、功能強大、用戶體驗好、性價比高、打開快等等，這些對于網站建設都非常重要，創新互聯公司通過對建站技術性的掌握、對創意設計的研究為客戶提供一站式互聯網解決方案，攜手廣大客戶，共同發展進步。
通常，我們習慣的業務建模方式是圍繞數據表的，先根據業務需要設計數據庫，再完成業務流程的開發。
在實現層面采用MVC分層框架，業務數據在3個層級之間流動（數據的流動性本質）。
雖然采用了MVC分層設計，但是在業務流程實現上仍舊是面向過程式，通常遵循這樣的開發模式：取數據 -> 處理數據 -> 存儲數據，是一種以數據為中心的過程式思想。
大家可以思考一下，你是不是也是這樣開發業務的？
該理論提出了一種新的分層模式，核心是強調面向對象。
interfaces是表現層，仍舊負責數據渲染，比如渲染頁面，渲染json等等。
domain是領域層，是指具體的某一類實體與操作的類封裝，比如訂單與訂單相關的操作。
application是應用層，組裝多個domain，組成一個具體的業務流程，比如交易下單流程，可能需要調用訂單、用戶、反作弊等等domain。
對于訂單來說，我們傳統MVC通常只把它當做數據庫記錄，是一個”貧血模型”，里面只有訂單的各個屬性列，通過調用model層從數據庫獲取。同時，我們會寫一個service層，封裝對訂單記錄的業務操作方法，即過程式的面向數據的開發模式。
而DDD則不同，它強調訂單是一類實體，具體某一條訂單則對應一個訂單對象。訂單對象具有自己的業務處理方法，數據和方法是封裝在一起的。
此時，如果創建訂單需要獲取用戶信息，那么就需要application層來做組裝：先獲取用戶對象，再調用訂單對象的方法傳入用戶對象來完成下單的一個流程。
application就是來做具體業務流程的一層，進行多個domain的組裝。
沒有銀彈，多參考不同的思想，目標是如何優化業務設計與定制高效的開發規范。
我感覺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分層架構是怎么樣的”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
