面試的時候被問到有關 MVC 的問題，雖然這塊知識點并不難，但還是總結一下，下次再遇到的話，爭取能做到侃侃而談，而不是簡簡單單把概念給復述一遍，
什么是 MVC？
MVC 模型代表 Model - View - Controller，即模型 - 視圖 - 控制器模式，從上到下依次介紹：
-
View（視圖）
簡單來說，就是負責資料的可視化，
-
Controller（控制器）
通常控制器用來從視圖讀取資料，并發送給對應的模型處理，再將結果反饋給視圖顯示，充當視圖與模型之間資料互動的橋梁，
-
Model（模型）
模型是用于處理應用程式中業務資料和邏輯的部分，負責直接與資料庫打交道，
為什么使用 MVC？
MVC 屬于架構模式的一種，所謂架構就是如何設計一個程式的結構，MVC 將程式結構劃分為三層，每一層都對外提供了可供上層呼叫的介面，既能維系三層之間的聯系，也能保持相對的獨立性，
而每一層都有各自的職責，我們可以將同一邏輯的代碼聚集到一個組件，再放到對應的層次中，視圖層作個性化的定制頁面，而無需知曉下層業務的具體實作，同樣的，控制層專心協調視圖與模型的資料互動，模型層處理業務邏輯，無需關心資料該如何顯示，
這種將業務邏輯、資料和界面分離的代碼組織形式，降低了模塊間的耦合度，有利于日后的維護與擴展，
MVC 的理解誤區
先說控制層，為什么要把控制層單獨拎出來說呢？因為很多人都誤解了 MVC 的真正含義，他們只是把簡單地把程式劃分為三層設計，并沒有理解到 MVC 的內涵，
前面已經說了，控制層只是負載協調視圖層與模型層的資料互動，就像一個粘合劑，把視圖層和模型層聯系起來，除此之外再無其他，而有的程式員卻喜歡在控制層寫大量的業務處理代碼，這是十分不合適的，
如果這樣做了，那 MVC 的優勢不就被你自己親手扼殺了嗎？MVC 的核心思想是 Controller 可以自由呼叫 Model，Model 之間的互相呼叫亦是如此，這是 MVC 的精髓所在，而 Controller 之間是不可以互相呼叫的，試問此時你要如何復用 Controller 中的業務代碼呢？
所以說各司其職很重要，不要胡亂指派任務，否則就是在給自己挖坑，
另外，很多人都知道 Controller - Service - Dao 三層架構，其中 Controller 和 Service 我們可以認為就是 MVC 中的控制層和模型層，而 Dao 其實不屬于 MVC，Dao 封裝了訪問資料訪問的代碼，Service 則去呼叫 Dao 提供的介面來處理資料，僅此而已，
MVC 的優點
-
耦合性低
視圖層和業務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的業務流程或者業務規則的改變只需要改動 MVC 的模型層即可，因為模型與控制器和視圖相分離，所以很容易改變應用程式的資料層和業務規則，
-
重用性高
一個模型能被多個視圖共享，這意味著從模型傳回來的資料能以多種方式顯示，而不需要為每一種顯示方式撰寫特定的代碼，大大減少了代碼量，
-
部署快
使用 MVC 模式使開發時間得到相當大的縮減，后臺程式員集中精力于業務邏輯，前端程式員集中精力于表現形式上，
-
可維護性高
分離視圖層和業務邏輯層也使得 WEB 應用更易于維護和修改，
-
有利軟體工程化管理
由于不同的層各司其職，每一層不同的應用具有某些相同的特征，有利于通過工程化、工具化管理程式代碼，
MVC 的缺點
-
增加系統結構和實作的復雜性
對于簡單的界面，嚴格遵循 MVC，使模型、視圖與控制器分離，會增加結構的復雜性，并可能產生過多的更新操作，降低運行效率，所以說 MVC 不適合用于小型、中型應用程式，
-
視圖與控制器間的過于緊密的連接
視圖與控制器是相互分離，但卻是聯系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用，
-
視圖對模型資料的低效率訪問
依據模型操作介面的不同，視圖可能需要多次呼叫才能獲得足夠的顯示資料，對未變化資料的不必要的頻繁訪問，也將損害操作性能，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/106684.html
標籤：其他
下一篇：Class常量池