模型-視圖-展示器(MVP)是MVC設(shè)計(jì)模式的一個(gè)衍生模式,它專(zhuān)注于提升展現(xiàn)邏輯.它來(lái)自于上個(gè)世紀(jì)九十年代早期的一個(gè)叫做Taligent的公司,當(dāng)時(shí)他們正工作于一個(gè)基于C++ CommonPoint環(huán)境的模型.而MVC和MVP的目標(biāo)都直指對(duì)整個(gè)多組件關(guān)注點(diǎn)的分離,它們之間有一些基礎(chǔ)上的不同。

為了要做出總結(jié)的目的,我們將專(zhuān)注于最適合于基于Web架構(gòu)的MVP版本。

模型,視圖&展示器

MVP中的P代表展示器.它是一個(gè)包含視圖的用戶界面邏輯的組件.不像MVC,來(lái)自視圖的調(diào)用被委派給了展示器,它是從視圖中解耦出來(lái)的,并且轉(zhuǎn)而通過(guò)一個(gè)接口來(lái)同它進(jìn)行對(duì)話.這允許所有類(lèi)型的有用的東西,比如在單元測(cè)試中模擬視圖的調(diào)用。

對(duì)MVP最通常的實(shí)現(xiàn)是使用一個(gè)被動(dòng)視圖(Passive View 一種對(duì)所有動(dòng)機(jī)和目的保持靜默的視圖),包含很少甚至與沒(méi)有任何邏輯.如果MVC和MVP是不同的,那是因?yàn)槠銫和P干了不同的事情.在MVP中,P觀察著模型并且當(dāng)模型發(fā)生改變的時(shí)候?qū)σ晥D進(jìn)行更新.P切實(shí)的將模型綁定到了視圖,這一責(zé)任在MVC中被控制器提前持有了。

通過(guò)視圖發(fā)送請(qǐng)求，展示者執(zhí)行所有和用戶請(qǐng)求相關(guān)的工作，并且把數(shù)據(jù)返回給視圖。從這個(gè)方面來(lái)講，它們獲取數(shù)據(jù)，操作數(shù)據(jù)，然后決定數(shù)據(jù)如何在視圖上面展示。在一些實(shí)現(xiàn)當(dāng)中，展示者同時(shí)和一個(gè)服務(wù)層交互，用于持久化數(shù)據(jù)（模型）。模型可以觸發(fā)事件，但是是由展示者扮演這個(gè)角色，用于訂閱這些事件，從而來(lái)更新視圖。在這個(gè)被動(dòng)體系架構(gòu)下，我們沒(méi)有直接數(shù)據(jù)綁定的概念。視圖暴露setter ，而展示者使用這些setter 來(lái)設(shè)置數(shù)據(jù)。

相較于MVC模式的這個(gè)改變所帶來(lái)的好處是，增強(qiáng)了我們應(yīng)用的可測(cè)試性，并且提供了一個(gè)更加干凈的視圖和模型之間的隔離。但是在這個(gè)模式里面伴隨著缺乏數(shù)據(jù)綁定支持的缺陷，這就意味著必須對(duì)這個(gè)任務(wù)做另外的處理。

盡管被動(dòng)視圖實(shí)現(xiàn)起來(lái)普遍都是為視圖和實(shí)現(xiàn)一個(gè)接口，但在它之上還是有差異的，包括可以更多的把視圖從展示器解耦的事件的使用。由于在Javascript中我們并沒(méi)有接口的構(gòu)造，我們這里更多的是使用一種約定而不是一個(gè)明確的接口。技術(shù)上看它仍然是一個(gè)接口，而從那個(gè)角度對(duì)于我們而言把它作為一個(gè)接口引用可能更加說(shuō)得過(guò)去一些。

也有一種叫做監(jiān)督控制器的MVP的變種，它更加接近于MVC和MVVM模式，因?yàn)樗峁┝藖?lái)自于直接來(lái)源于視圖的模型的數(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ì)來(lái)說(shuō)并不怎么滿足需求，因?yàn)橐鉀Q這個(gè)問(wèn)題可能意味著對(duì)多重控制器的重度依賴。在MVP中，所有這些復(fù)雜的邏輯能夠被封裝到一個(gè)展示器中，它可以顯著的簡(jiǎn)化維護(hù)工作量。

由于MVP的視圖是通過(guò)一個(gè)接口來(lái)被定義的，而這個(gè)接口在技術(shù)上唯一的要點(diǎn)只是系統(tǒng)和視圖（展示器除外）之間接觸，這一模式也允許開(kāi)發(fā)者不需要等待設(shè)計(jì)師為應(yīng)用程序制作出布局和圖形，就可以開(kāi)始編寫(xiě)展現(xiàn)邏輯。

根據(jù)其實(shí)現(xiàn)，MVP也許MVC更加容易進(jìn)行自動(dòng)的單元測(cè)試。為此常常被提及的理由是展示器可以被當(dāng)做用戶接口的完全模擬來(lái)使用，而因此它能夠獨(dú)立于其它組件接受單元測(cè)試。在我的經(jīng)驗(yàn)中這取決于我們正在實(shí)現(xiàn)的MVP所使用的語(yǔ)言（超過(guò)一種取代Javascript來(lái)實(shí)現(xiàn)MVP的可選語(yǔ)言，同Javascript有著相當(dāng)大的不同，比如說(shuō)ASP.net）。

在一天的終點(diǎn)，我們對(duì)MVC可能會(huì)有的底層關(guān)注，可能將是保持對(duì)MVP的認(rèn)可，因?yàn)樗鼈冎g的不同主要是在語(yǔ)義上的。一旦我們對(duì)清晰分離的關(guān)注被納入到模型、視圖和控制器（或者展示器）中，我們也許會(huì)獲得大部分同樣的好處，而不用去管我們所作出的選擇的差異。

MVC, MVP 和 Backbone.js

很少有，但是如果有任何架構(gòu)性質(zhì)的Javascript框架聲稱(chēng)用其經(jīng)典形式實(shí)現(xiàn)了MVC或者M(jìn)VP模式的話，那是因?yàn)樵S多開(kāi)發(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í)，她需要某些東西來(lái)實(shí)際為她組裝它們。這可以是一個(gè)控制器路由（比如Backbone.Router，在本書(shū)的后面會(huì)提到）或者一個(gè)對(duì)被獲取數(shù)據(jù)做出響應(yīng)的回調(diào)。

這就是說(shuō)，一些開(kāi)發(fā)者確實(shí)感覺(jué)Backbone.js更加適合于MVP的描述，相比于MVC。他們的觀點(diǎn)是：

• 相比于控制器，MVP中的展示器更好的描述了Backbone.View（視圖模板和綁定在視圖模板之上的數(shù)據(jù)之間的中間層）。
• 模型適合Backbone.Model（相較于MVC中的模型并沒(méi)有很大的不同）。
• 視圖最能代表模板（比如 Handlebars/Mustache標(biāo)記模板）

對(duì)此的回應(yīng)會(huì)是視圖也可以是一個(gè)View（如MVC），因?yàn)锽ackbone對(duì)于讓它用于多用途有足夠的彈性。MVC中的V和MVP中的P都能夠通過(guò)Backbone.View來(lái)完成，因?yàn)樗鼈兡軌蜻_(dá)成兩個(gè)目標(biāo)：都用來(lái)渲染原子組件，還有將那個(gè)組件組裝起來(lái)讓其它視圖來(lái)渲染。

我們也已經(jīng)看到Backbone中控制器的責(zé)任Backbone.View和Backbone.Router都有分享，而在下面的示例中我們能夠?qū)嶋H看到那方面實(shí)際上都是千真萬(wàn)確的。

在this.model.bind("change",..)一行中，我們的BackbonePhotoView使用了觀察者模式來(lái)對(duì)視圖的改變進(jìn)行“訂閱”。它也處理render()方法中的模板，但是并不像一些其它的實(shí)現(xiàn)，用戶交互也在視圖中處理（見(jià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更加向我們前面考察過(guò)的Smalltalk-80MVC靠攏。

定期為Backbone寫(xiě)博客的Derick Bailey之前已經(jīng)提到過(guò)，最終最好不要去強(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)典模式，不管是有意還是無(wú)意為之的，最重要的是它們幫助了我們有組織，干凈的來(lái)開(kāi)發(fā)方便維護(hù)的應(yīng)用程序。