1. MVC框架

MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設(shè)計(jì)典范，用一種業(yè)務(wù)邏輯、數(shù)據(jù)、界面顯示分離的方法組織代碼，將業(yè)務(wù)邏輯聚集到一個(gè)部件里面，在改進(jìn)和個(gè)性化定制界面及用戶交互的同時(shí)，不需要重新編寫業(yè)務(wù)邏輯。MVC被獨(dú)特的發(fā)展起來用于映射傳統(tǒng)的輸入、處理和輸出功能在一個(gè)邏輯的圖形化用戶界面的結(jié)構(gòu)中。

MVC框架模式圖

1.1 MVC 編程模式

MVC 是一種使用 MVC（Model View Controller 模型-視圖-控制器）設(shè)計(jì)創(chuàng)建 Web 應(yīng)用程序的模式： ^[1]

• Model（模型）表示應(yīng)用程序核心（如數(shù)據(jù)庫）。

• View（視圖）顯示效果（HTML頁面）。

• Controller（控制器）處理輸入（業(yè)務(wù)邏輯）。

MVC 模式同時(shí)提供了對(duì) HTML、CSS 和 JavaScript 的完全控制。

Model（模型）是應(yīng)用程序中用于處理應(yīng)用程序數(shù)據(jù)邏輯的部分。
　　通常模型對(duì)象負(fù)責(zé)在數(shù)據(jù)庫中存取數(shù)據(jù)。

View（視圖）是應(yīng)用程序中處理數(shù)據(jù)顯示的部分。
　　通常視圖是依據(jù)模型數(shù)據(jù)創(chuàng)建的。

Controller（控制器）是應(yīng)用程序中處理用戶交互的部分。
　　通?？刂破髫?fù)責(zé)從視圖讀取數(shù)據(jù)，控制用戶輸入，并向模型發(fā)送數(shù)據(jù)。

優(yōu)點(diǎn)

耦合性低

視圖層和業(yè)務(wù)層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個(gè)應(yīng)用的業(yè)務(wù)流程或者業(yè)務(wù)規(guī)則的改變只需要改動(dòng)MVC的模型層即可。因?yàn)槟Ｐ团c控制器和視圖相分離，所以很容易改變應(yīng)用程序的數(shù)據(jù)層和業(yè)務(wù)規(guī)則。

模型是自包含的，并且與控制器和視圖相分離，所以很容易改變應(yīng)用程序的數(shù)據(jù)層和業(yè)務(wù)規(guī)則。如果把數(shù)據(jù)庫從MySQL移植到Oracle，或者改變基于RDBMS數(shù)據(jù)源到LDAP，只需改變模型即可。一旦正確的實(shí)現(xiàn)了模型，不管數(shù)據(jù)來自數(shù)據(jù)庫或是LDAP服務(wù)器，視圖將會(huì)正確的顯示它們。由于運(yùn)用MVC的應(yīng)用程序的三個(gè)部件是相互獨(dú)立，改變其中一個(gè)不會(huì)影響其它兩個(gè)，所以依據(jù)這種設(shè)計(jì)思想能構(gòu)造良好的松耦合

重用性高

隨著技術(shù)的不斷進(jìn)步，需要用越來越多的方式來訪問應(yīng)用程序。MVC模式允許使用各種不同樣式的視圖來訪問同一個(gè)服務(wù)器端的代碼，因?yàn)槎鄠€(gè)視圖能共享一個(gè)模型，它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，用戶可以通過電腦也可通過手機(jī)來訂購(gòu)某樣產(chǎn)品，雖然訂購(gòu)的方式不一樣，但處理訂購(gòu)產(chǎn)品的方式是一樣的。由于模型返回的數(shù)據(jù)沒有進(jìn)行格式化，所以同樣的構(gòu)件能被不同的界面使用。例如，很多數(shù)據(jù)可能用HTML來表示，但是也有可能用WAP來表示，而這些表示所需要的命令是改變視圖層的實(shí)現(xiàn)方式，而控制層和模型層無需做任何改變。由于已經(jīng)將數(shù)據(jù)和業(yè)務(wù)規(guī)則從表示層分開，所以可以最大化的重用代碼了。模型也有狀態(tài)管理和數(shù)據(jù)持久性處理的功能，例如，基于會(huì)話的購(gòu)物車和電子商務(wù)過程也能被Flash網(wǎng)站或者無線聯(lián)網(wǎng)的應(yīng)用程序所重用。 ^[11]

生命周期成本低

MVC使開發(fā)和維護(hù)用戶接口的技術(shù)含量降低。

部署快

使用MVC模式使開發(fā)時(shí)間得到相當(dāng)大的縮減，它使程序員（Java開發(fā)人員）集中精力于業(yè)務(wù)邏輯，界面程序員（HTML和JSP開發(fā)人員）集中精力于表現(xiàn)形式上。

可維護(hù)性高

分離視圖層和業(yè)務(wù)邏輯層也使得WEB應(yīng)用更易于維護(hù)和修改。

有利軟件工程化管理

由于不同的層各司其職，每一層不同的應(yīng)用具有某些相同的特征，有利于通過工程化、工具化管理程序代碼?？刂破饕蔡峁┝艘粋€(gè)好處，就是可以使用控制器來聯(lián)接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構(gòu)造應(yīng)用程序提供強(qiáng)有力的手段。給定一些可重用的模型和視圖，控制器可以根據(jù)用戶的需求選擇模型進(jìn)行處理，然后選擇視圖將處理結(jié)果顯示給用戶。

缺點(diǎn)

沒有明確的定義

完全理解MVC并不是很容易。使用MVC需要精心的計(jì)劃，由于它的內(nèi)部原理比較復(fù)雜，所以需要花費(fèi)一些時(shí)間去思考。同時(shí)由于模型和視圖要嚴(yán)格的分離，這樣也給調(diào)試應(yīng)用程序帶來了一定的困難。每個(gè)構(gòu)件在使用之前都需要經(jīng)過徹底的測(cè)試。

不適合小型，中等規(guī)模的應(yīng)用程序

花費(fèi)大量時(shí)間將MVC應(yīng)用到規(guī)模并不是很大的應(yīng)用程序通常會(huì)得不償失。

增加系統(tǒng)結(jié)構(gòu)和實(shí)現(xiàn)的復(fù)雜性

對(duì)于簡(jiǎn)單的界面，嚴(yán)格遵循MVC，使模型、視圖與控制器分離，會(huì)增加結(jié)構(gòu)的復(fù)雜性，并可能產(chǎn)生過多的更新操作，降低運(yùn)行效率。

視圖與控制器間的過于緊密的連接

視圖與控制器是相互分離，但卻是聯(lián)系緊密的部件，視圖沒有控制器的存在，其應(yīng)用是很有限的，反之亦然，這樣就妨礙了他們的獨(dú)立重用。

視圖對(duì)模型數(shù)據(jù)的低效率訪問

依據(jù)模型操作接口的不同，視圖可能需要多次調(diào)用才能獲得足夠的顯示數(shù)據(jù)。對(duì)未變化數(shù)據(jù)的不必要的頻繁訪問，也將損害操作性能。

一般高級(jí)的界面工具或構(gòu)造器不支持模式

改造這些工具以適應(yīng)MVC需要和建立分離的部件的代價(jià)是很高的，會(huì)造成MVC使用的困難。

2. MVP模式

全稱：Model-View-Presenter ；MVP 是從經(jīng)典的模式MVC演變而來，它們的基本思想有相通的地方Controller/Presenter負(fù)責(zé)邏輯的處理，Model提供數(shù)據(jù)，View負(fù)責(zé)顯示。

MVP框架模式圖

優(yōu)點(diǎn)

1、模型與視圖完全分離，我們可以修改視圖而不影響模型

2、可以更高效地使用模型，因?yàn)樗械慕换ザ及l(fā)生在一個(gè)地方——Presenter內(nèi)部

3、我們可以將一個(gè)Presenter用于多個(gè)視圖，而不需要改變Presenter的邏輯。這個(gè)特性非常的有用，因?yàn)橐晥D的變化總是比模型的變化頻繁。

4、如果我們把邏輯放在Presenter中，那么我們就可以脫離用戶接口來測(cè)試這些邏輯（單元測(cè)試）

缺點(diǎn)

由于對(duì)視圖的渲染放在了Presenter中，所以視圖和Presenter的交互會(huì)過于頻繁。還有一點(diǎn)需要明白，如果Presenter過多地渲染了視圖，往往會(huì)使得它與特定的視圖的聯(lián)系過于緊密。一旦視圖需要變更，那么Presenter也需要變更了。比如說，原本用來呈現(xiàn)Html的Presenter現(xiàn)在也需要用于呈現(xiàn)Pdf了，那么視圖很有可能也需要變更。

MVP與MVC區(qū)別：

作為一種新的模式，MVP與MVC有著一個(gè)重大的區(qū)別：在MVP中View并不直接使用Model，它們之間的通信是通過Presenter (MVC中的Controller)來進(jìn)行的，所有的交互都發(fā)生在Presenter內(nèi)部，而在MVC中View會(huì)直接從Model中讀取數(shù)據(jù)而不是通過 Controller。
在MVC里，View是可以直接訪問Model的！從而，View里會(huì)包含Model信息，不可避免的還要包括一些業(yè)務(wù)邏輯。 在MVC模型里，更關(guān)注的Model的改變，而同時(shí)有多個(gè)對(duì)Model的不同顯示，即View。所以，在MVC模型里，Model不依賴于View，但是View是依賴于Model的。不僅如此，因?yàn)橛幸恍I(yè)務(wù)邏輯在View里實(shí)現(xiàn)了，導(dǎo)致要更改View也是比較困難的，至少那些業(yè)務(wù)邏輯是無法重用的。
雖然 MVC 中的 View 的確“可以”訪問 Model，但是我們不建議在 View 中依賴 Model，而是要求盡可能把所有業(yè)務(wù)邏輯都放在 Controller 中處理，而 View 只和 Controller 交互。

區(qū)別如下圖所示：

mvc.png

mvp.png

3.MVVM框架

MVVM是Model-View-ViewModel的簡(jiǎn)寫。它本質(zhì)上就是MVC 的改進(jìn)版。MVVM 就是將其中的View 的狀態(tài)和行為抽象化，讓我們將視圖 UI 和業(yè)務(wù)邏輯分開。當(dāng)然這些事 ViewModel 已經(jīng)幫我們做了，它可以取出 Model 的數(shù)據(jù)同時(shí)幫忙處理 View 中由于需要展示內(nèi)容而涉及的業(yè)務(wù)邏輯。微軟的WPF帶來了新的技術(shù)體驗(yàn)，如Silverlight、音頻、視頻、3D、動(dòng)畫……，這導(dǎo)致了軟件UI層更加細(xì)節(jié)化、可定制化。同時(shí)，在技術(shù)層面，WPF也帶來了 諸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM（Model-View-ViewModel）框架的由來便是MVP（Model-View-Presenter）模式與WPF結(jié)合的應(yīng)用方式時(shí)發(fā)展演變過來的一種新型架構(gòu)框架。它立足于原有MVP框架并且把WPF的新特性糅合進(jìn)去，以應(yīng)對(duì)客戶日益復(fù)雜的需求變化。

MVVM框架模式圖

3.1 MVVM模式的組成部分

• 模型

• 模型是指代表真實(shí)狀態(tài)內(nèi)容的領(lǐng)域模型（面向?qū)ο螅蛑复韮?nèi)容的數(shù)據(jù)訪問層（以數(shù)據(jù)為中心）。

• 視圖

• 就像在MVC和MVP模式中一樣，視圖是用戶在屏幕上看到的結(jié)構(gòu)、布局和外觀（UI）。

• 視圖模型

• 視圖模型是暴露公共屬性和命令的視圖的抽象。MVVM沒有MVC模式的控制器，也沒有MVP模式的presenter，有的是一個(gè)綁定器。在視圖模型中，綁定器在視圖和數(shù)據(jù)綁定器之間進(jìn)行通信。

• 綁定器

• 聲明性數(shù)據(jù)和命令綁定隱含在MVVM模式中。在Microsoft解決方案堆中，綁定器是一種名為XAML的標(biāo)記語言。綁定器使開發(fā)人員免于被迫編寫樣板式邏輯來同步視圖模型和視圖。在微軟的堆之外實(shí)現(xiàn)時(shí)，聲明性數(shù)據(jù)綁定技術(shù)的出現(xiàn)是實(shí)現(xiàn)該模式的一個(gè)關(guān)鍵因素。 ^[1]

3.2 MVVM優(yōu)點(diǎn)

MVVM模式和MVC模式一樣，主要目的是分離視圖（View）和模型（Model），有幾大優(yōu)點(diǎn)

1. 低耦合。視圖（View）可以獨(dú)立于Model變化和修改，一個(gè)ViewModel可以綁定到不同的"View"上，當(dāng)View變化的時(shí)候Model可以不變，當(dāng)Model變化的時(shí)候View也可以不變。

2. 可重用性。你可以把一些視圖邏輯放在一個(gè)ViewModel里面，讓很多view重用這段視圖邏輯。

3. 獨(dú)立開發(fā)。開發(fā)人員可以專注于業(yè)務(wù)邏輯和數(shù)據(jù)的開發(fā)（ViewModel），設(shè)計(jì)人員可以專注于頁面設(shè)計(jì)，使用Expression Blend可以很容易設(shè)計(jì)界面并生成xaml代碼。

4. 可測(cè)試。界面素來是比較難于測(cè)試的，而現(xiàn)在測(cè)試可以針對(duì)ViewModel來寫。

3.2 MVVM與MVP區(qū)別：

mvvm模式將Presener改名為View Model，基本上與MVP模式完全一致，唯一的區(qū)別是，它采用雙向綁定(data-binding): View的 變動(dòng)，自動(dòng)反映在View Model，反之亦然。這樣開發(fā)者就不用處理接收事件和View更新的工作，框架已經(jīng)幫你做好了。

文章小結(jié)（作者感言）：

這些模式是依次進(jìn)化而形成MVC/MVP—>MVVM。在以前傳統(tǒng)的開發(fā)模式當(dāng)中即MVC模式，前端人員只負(fù)責(zé)Model（數(shù)據(jù)庫） View（視圖） Controller /Presenter/ViewModel（控制器） 當(dāng)中的View（視圖）部分，寫好頁面交由后端創(chuàng)建渲染模板并提供數(shù)據(jù)，隨著MVVM模式的出現(xiàn)前端已經(jīng)可以自己寫業(yè)務(wù)邏輯以及渲染模板，后端只負(fù)責(zé)提供數(shù)據(jù)即可，前端所能做的事情越來越多，這并非壞事，我們的能力得到了提升，并且在開發(fā)項(xiàng)目當(dāng)中工作所占比重更大，這樣一想是不是很開心了呢？好了，今天就介紹到這里~