MVP
（MVP 模式）
mvp的全稱為Model-View-Presenter，Model提供數(shù)據(jù)，View負(fù)責(zé)顯示，Controller/Presenter負(fù)責(zé)邏輯的處理。MVP與MVC有著一個重大的區(qū)別：在MVP中View并不直接使用Model，它們之間的通信是通過Presenter (MVC中的Controller)來進(jìn)行的，所有的交互都發(fā)生在Presenter內(nèi)部，而在MVC中View會直接從Model中讀取數(shù)據(jù)而不是通過 Controller。
中文名
MVP
外文名
Model-View-Presenter
通信方式
Presenter
位????置
在Presenter內(nèi)部
目錄
MVC和MVP
MVP 是從經(jīng)典的模式MVC演變而來，它們的基本思想有相通的地方：Controller/Presenter負(fù)責(zé)邏輯的處理，Model提供數(shù)據(jù)，View負(fù)責(zé)顯示。作為一種新的模式，MVP與MVC有著一個重大的區(qū)別：在MVP中View并不直接使用Model，它們之間的通信是通過Presenter (MVC中的Controller)來進(jìn)行的，所有的交互都發(fā)生在Presenter內(nèi)部，而在MVC中View會從直接Model中讀取數(shù)據(jù)而不是通過 Controller。
在MVC里，View是可以直接訪問Model的！從而，View里會包含Model信息，不可避免的還要包括一些業(yè)務(wù)邏輯。 在MVC模型里，更關(guān)注的Model的不變，而同時(shí)有多個對Model的不同顯示，及View。所以，在MVC模型里，Model不依賴于View，但是View是依賴于Model的。不僅如此，因?yàn)橛幸恍I(yè)務(wù)邏輯在View里實(shí)現(xiàn)了，導(dǎo)致要更改View也是比較困難的，至少那些業(yè)務(wù)邏輯是無法重用的。[1]
解決MVC問題
在MVP里，Presenter完全把Model和View進(jìn)行了分離，主要的程序邏輯在Presenter里實(shí)現(xiàn)。而且，Presenter與具體的View是沒有直接關(guān)聯(lián)的，而是通過定義好的接口進(jìn)行交互，從而使得在變更View時(shí)候可以保持Presenter的不變，即重用！ 不僅如此，我們還可以編寫測試用的View，模擬用戶的各種操作，從而實(shí)現(xiàn)對Presenter的測試--而不需要使用自動化的測試工具。 我們甚至可以在Model和View都沒有完成時(shí)候，就可以通過編寫Mock Object（即實(shí)現(xiàn)了Model和View的接口，但沒有具體的內(nèi)容的）來測試Presenter的邏輯。 在MVP里，應(yīng)用程序的邏輯主要在Presenter來實(shí)現(xiàn)，其中的View是很薄的一層。因此就有人提出了Presenter First的設(shè)計(jì)模式，就是根據(jù)User Story來首先設(shè)計(jì)和開發(fā)Presenter。在這個過程中，View是很簡單的，能夠把信息顯示清楚就可以了。在后面，根據(jù)需要再隨便更改View，而對Presenter沒有任何的影響了。 如果要實(shí)現(xiàn)的UI比較復(fù)雜，而且相關(guān)的顯示邏輯還跟Model有關(guān)系，就可以在View和Presenter之間放置一個Adapter。由這個 Adapter來訪問Model和View，避免兩者之間的關(guān)聯(lián)。而同時(shí)，因?yàn)锳dapter實(shí)現(xiàn)了View的接口，從而可以保證與Presenter之間接口的不變。這樣就可以保證View和Presenter之間接口的簡潔，又不失去UI的靈活性。 在MVP模式里，View只應(yīng)該有簡單的Set/Get的方法，用戶輸入和設(shè)置界面顯示的內(nèi)容，除此就不應(yīng)該有更多的內(nèi)容，絕不容許直接訪問Model--這就是與MVC很大的不同之處。[1]
優(yōu)點(diǎn)
1、模型與視圖完全分離，我們可以修改視圖而不影響模型
2、可以更高效地使用模型，因?yàn)樗械慕换ザ及l(fā)生在一個地方——Presenter內(nèi)部
3、我們可以將一個Presenter用于多個視圖，而不需要改變Presenter的邏輯。這個特性非常的有用，因?yàn)橐晥D的變化總是比模型的變化頻繁。
4、如果我們把邏輯放在Presenter中，那么我們就可以脫離用戶接口來測試這些邏輯（單元測試）[1]
缺點(diǎn)
由于對視圖的渲染放在了Presenter中，所以視圖和Presenter的交互會過于頻繁。還有一點(diǎn)需要明白，如果Presenter過多地渲染了視圖，往往會使得它與特定的視圖的聯(lián)系過于緊密。一旦視圖需要變更，那么Presenter也需要變更了。比如說，原本用來呈現(xiàn)Html的Presenter現(xiàn)在也需要用于呈現(xiàn)Pdf了，那么視圖很有可能也需要變更。
