# MVP
模型-視圖-展示器(MVP)是MVC設(shè)計(jì)模式的一個(gè)衍生模式,它專注于提升展現(xiàn)邏輯.它來自于上個(gè)世紀(jì)九十年代早期的一個(gè)叫做Taligent的公司,當(dāng)時(shí)他們正工作于一個(gè)基于C++ CommonPoint環(huán)境的模型.而MVC和MVP的目標(biāo)都直指對(duì)整個(gè)多組件關(guān)注點(diǎn)的分離,它們之間有一些基礎(chǔ)上的不同。
為了要做出總結(jié)的目的,我們將專注于最適合于基于Web架構(gòu)的MVP版本。
## 模型,視圖&展示器
MVP中的P代表展示器.它是一個(gè)包含視圖的用戶界面邏輯的組件.不像MVC,來自視圖的調(diào)用被委派給了展示器,它是從視圖中解耦出來的,并且轉(zhuǎn)而通過一個(gè)接口來同它進(jìn)行對(duì)話.這允許所有類型的有用的東西,比如在單元測(cè)試中模擬視圖的調(diào)用。
對(duì)MVP最通常的實(shí)現(xiàn)是使用一個(gè)被動(dòng)視圖(Passive View 一種對(duì)所有動(dòng)機(jī)和目的保持靜默的視圖),包含很少甚至與沒有任何邏輯.如果MVC和MVP是不同的,那是因?yàn)槠銫和P干了不同的事情.在MVP中,P觀察著模型并且當(dāng)模型發(fā)生改變的時(shí)候?qū)σ晥D進(jìn)行更新.P切實(shí)的將模型綁定到了視圖,這一責(zé)任在MVC中被控制器提前持有了。
通過視圖發(fā)送請(qǐng)求，展示者執(zhí)行所有和用戶請(qǐng)求相關(guān)的工作，并且把數(shù)據(jù)返回給視圖。從這個(gè)方面來講，它們獲取數(shù)據(jù)，操作數(shù)據(jù)，然后決定數(shù)據(jù)如何在視圖上面展示。在一些實(shí)現(xiàn)當(dāng)中，展示者同時(shí)和一個(gè)服務(wù)層交互，用于持久化數(shù)據(jù)（模型）。模型可以觸發(fā)事件，但是是由展示者扮演這個(gè)角色，用于訂閱這些事件，從而來更新視圖。在這個(gè)被動(dòng)體系架構(gòu)下，我們沒有直接數(shù)據(jù)綁定的概念。視圖暴露setter ，而展示者使用這些setter 來設(shè)置數(shù)據(jù)。
相較于MVC模式的這個(gè)改變所帶來的好處是，增強(qiáng)了我們應(yīng)用的可測(cè)試性，并且提供了一個(gè)更加干凈的視圖和模型之間的隔離。但是在這個(gè)模式里面伴隨著缺乏數(shù)據(jù)綁定支持的缺陷，這就意味著必須對(duì)這個(gè)任務(wù)做另外的處理。
盡管被動(dòng)視圖實(shí)現(xiàn)起來普遍都是為視圖和實(shí)現(xiàn)一個(gè)接口，但在它之上還是有差異的，包括可以更多的把視圖從展示器解耦的事件的使用。由于在Javascript中我們并沒有接口的構(gòu)造，我們這里更多的是使用一種約定而不是一個(gè)明確的接口。技術(shù)上看它仍然是一個(gè)接口，而從那個(gè)角度對(duì)于我們而言把它作為一個(gè)接口引用可能更加說得過去一些。
也有一種叫做監(jiān)督控制器的MVP的變種，它更加接近于MVC和MVVM模式，因?yàn)樗峁┝藖碜杂谥苯觼碓从谝晥D的模型的數(shù)據(jù)綁定。鍵值觀察（KVO）插件（比如Derick Bailey的Backbone.ModelBingding插件）趨向于吧Backbone帶出被動(dòng)視圖的范疇，而更多的帶入監(jiān)督控制器和MVVM變異中。
## MVP還是MVC？
MVP一般最常使用在企業(yè)級(jí)應(yīng)用程序中，這樣的程序中有必要對(duì)展現(xiàn)邏輯盡可能的重用。帶有非常復(fù)雜的邏輯和大量用戶交互的應(yīng)用程序中，我們也許會(huì)發(fā)現(xiàn)MVC相對(duì)來說并不怎么滿足需求，因?yàn)橐鉀Q這個(gè)問題可能意味著對(duì)多重控制器的重度依賴。在MVP中，所有這些復(fù)雜的邏輯能夠被封裝到一個(gè)展示器中，它可以顯著的簡(jiǎn)化維護(hù)工作量。
由于MVP的視圖是通過一個(gè)接口來被定義的，而這個(gè)接口在技術(shù)上唯一的要點(diǎn)只是系統(tǒng)和視圖（展示器除外）之間接觸，這一模式也允許開發(fā)者不需要等待設(shè)計(jì)師為應(yīng)用程序制作出布局和圖形，就可以開始編寫展現(xiàn)邏輯。
根據(jù)其實(shí)現(xiàn)，MVP也許MVC更加容易進(jìn)行自動(dòng)的單元測(cè)試。為此常常被提及的理由是展示器可以被當(dāng)做用戶接口的完全模擬來使用，而因此它能夠獨(dú)立于其它組件接受單元測(cè)試。在我的經(jīng)驗(yàn)中這取決于我們正在實(shí)現(xiàn)的MVP所使用的語言（超過一種取代Javascript來實(shí)現(xiàn)MVP的可選語言，同Javascript有著相當(dāng)大的不同，比如說ASP.net）。
在一天的終點(diǎn)，我們對(duì)MVC可能會(huì)有的底層關(guān)注，可能將是保持對(duì)MVP的認(rèn)可，因?yàn)樗鼈冎g的不同主要是在語義上的。一旦我們對(duì)清晰分離的關(guān)注被納入到模型、視圖和控制器（或者展示器）中，我們也許會(huì)獲得大部分同樣的好處，而不用去管我們所作出的選擇的差異。
## MVC, MVP 和 Backbone.js
很少有，但是如果有任何架構(gòu)性質(zhì)的Javascript框架聲稱用其經(jīng)典形式實(shí)現(xiàn)了MVC或者M(jìn)VP模式的話，那是因?yàn)樵S多開發(fā)者并不認(rèn)為MVC和MVP是相互沖突的（看到諸如ASP.net或者GWT這樣的web框架，我們實(shí)際上更加可能會(huì)認(rèn)為MVP被嚴(yán)格的實(shí)現(xiàn)了）。這是因?yàn)樽屛覀兊膽?yīng)用程序有一個(gè)附加的展示器/視圖邏輯，同時(shí)也仍然當(dāng)其是一種MVC的意味，是有可能的。
Backbone貢獻(xiàn)者Irene Ros（位于波士頓的Bocoup）贊同這種想法，當(dāng)她將視圖分離到屬于它們自己的單獨(dú)組件中時(shí)，她需要某些東西來實(shí)際為她組裝它們。這可以是一個(gè)控制器路由（比如Backbone.Router，在本書的后面會(huì)提到）或者一個(gè)對(duì)被獲取數(shù)據(jù)做出響應(yīng)的回調(diào)。
這就是說，一些開發(fā)者確實(shí)感覺Backbone.js更加適合于MVP的描述，相比于MVC。他們的觀點(diǎn)是：
* 相比于控制器，MVP中的展示器更好的描述了Backbone.View（視圖模板和綁定在視圖模板之上的數(shù)據(jù)之間的中間層）。
* 模型適合Backbone.Model（相較于MVC中的模型并沒有很大的不同）。
* 視圖最能代表模板（比如 Handlebars/Mustache標(biāo)記模板）
對(duì)此的回應(yīng)會(huì)是視圖也可以是一個(gè)View（如MVC），因?yàn)锽ackbone對(duì)于讓它用于多用途有足夠的彈性。MVC中的V和MVP中的P都能夠通過Backbone.View來完成，因?yàn)樗鼈兡軌蜻_(dá)成兩個(gè)目標(biāo)：都用來渲染原子組件，還有將那個(gè)組件組裝起來讓其它視圖來渲染。
我們也已經(jīng)看到Backbone中控制器的責(zé)任Backbone.View和Backbone.Router都有分享，而在下面的示例中我們能夠?qū)嶋H看到那方面實(shí)際上都是千真萬確的。
在this.model.bind("change",..)一行中，我們的BackbonePhotoView使用了觀察者模式來對(duì)視圖的改變進(jìn)行“訂閱”。它也處理render()方法中的模板，但是并不像一些其它的實(shí)現(xiàn)，用戶交互也在視圖中處理（見events參數(shù)）。
~~~
var PhotoView = Backbone.View.extend({
//... is a list tag.
tagName: "li",
// Pass the contents of the photo template through a templating
// function, cache it for a single photo
template: _.template( $("#photo-template").html() ),
// The DOM events specific to an item.
events: {
"click img" : "toggleViewed"
},
// The PhotoView listens for changes to
// its model, re-rendering. Since tHere's
// a one-to-one correspondence between a
// **Photo** and a **PhotoView** in this
// app, we set a direct reference on the model for convenience.
initialize: function() {
this.model.on( "change", this.render, this );
this.model.on( "destroy", this.remove, this );
},
// Re-render the photo entry
render: function() {
$( this.el ).html( this.template(this.model.toJSON() ));
return this;
},
// Toggle the `"viewed"` state of the model.
toggleViewed: function() {
this.model.viewed();
}
});
~~~
另一種（完全不同的）看法是Backbone更加向我們前面考察過的Smalltalk-80MVC靠攏。
定期為Backbone寫博客的Derick Bailey之前已經(jīng)提到過，最終最好不要去強(qiáng)迫Backbone讓其適應(yīng)任何特定的設(shè)計(jì)模式。設(shè)計(jì)模式應(yīng)該考慮指導(dǎo)可能如何被構(gòu)建的靈活性，而在這一方面，Backbone既不適應(yīng)MVC，也不適應(yīng)MVP。相反，它從多個(gè)架構(gòu)模式中借用了一些最好的經(jīng)驗(yàn)而創(chuàng)造出了一個(gè)靈活的框架，并且工作得很好。
而理解這些這些概念源自哪里和為什么源自那里是值得去做的，因此我希望我對(duì)于MVC和MVP的闡述對(duì)此已經(jīng)有所幫助。就叫它Backbone方法吧，MV*或帶有的其它應(yīng)用程序架構(gòu)的意味。大多數(shù)結(jié)構(gòu)性Javascript框架自主決定自身采用的經(jīng)典模式，不管是有意還是無意為之的，最重要的是它們幫助了我們有組織，干凈的來開發(fā)方便維護(hù)的應(yīng)用程序。
- 前言
- 簡(jiǎn)介
- 什么是設(shè)計(jì)模式？
- 設(shè)計(jì)模式的結(jié)構(gòu)
- 編寫設(shè)計(jì)模式
- 反模式
- 設(shè)計(jì)模式的分類
- 設(shè)計(jì)模式分類概覽表
- JavaScript 設(shè)計(jì)模式
- 構(gòu)造器模式
- 模塊化模式
- 暴露模塊模式
- 單例模式
- 觀察者模式
- 中介者模式
- 原型模式
- 命令模式
- 外觀模式
- 工廠模式
- Mixin 模式
- 裝飾模式
- 亨元（Flyweight）模式
- JavaScript MV* 模式
- MVC 模式
- MVP 模式
- MVVM 模式
- 最新的模塊化 JavaScript 設(shè)計(jì)模式
- AMD
- CommonJS
- ES Harmony
- JQuery 中的設(shè)計(jì)模式
- 組合模式
- 適配器模式
- 外觀模式
- 觀察者模式
- 迭代器模式
- 惰性初始模式
- 代理模式
- 建造者模式
- jQuery 插件的設(shè)計(jì)模式
- JavaScript 命名空間模式
- 總結(jié)
- 參考