MVC 架構模式

面試的時候被問到有關 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 不適合用於小型、中型應用程序。

• 視圖與控制器間的過於緊密的鏈接

  視圖與控制器是相互分離，但倒是聯繫緊密的部件，視圖沒有控制器的存在，其應用是頗有限的，反之亦然，這樣就妨礙了他們的獨立重用。

• 視圖對模型數據的低效率訪問

  依據模型操做接口的不一樣，視圖可能須要屢次調用才能得到足夠的顯示數據。對未變化數據的沒必要要的頻繁訪問，也將損害操做性能。