雜項-JAVA：MVP
| ylbtech-雜項-JAVA：MVP |
簡稱：MVP 全稱：Model-View-Presenter ；MVP 是從經典的模式MVC演變而來，它們的基本思想有相通的地方：Controller/Presenter負責邏輯的處理，Model提供數據，View負責顯示。設計模式
| 1.返回頂部 |
一、
模式特色
做爲一種新的模式，
MVP與MVC有着一個重大的區別：在MVP中View並不直接使用Model，它們之間的通訊是經過Presenter (MVC中的Controller)來進行的，全部的交互都發生在Presenter內部，而在MVC中View會直接從Model中讀取數據而不是經過 Controller。
在MVC裏，View是能夠直接訪問Model的！從而，View裏會包含Model信息，不可避免的還要包括一些業務邏輯。 在MVC模型裏，更關注的Model的改變，而同時有多個對Model的不一樣顯示，即View。因此，在MVC模型裏，Model不依賴於View，可是View是依賴於Model的。不只如此，由於有一些業務邏輯在View裏實現了，致使要更改View也是比較困難的，至少那些業務邏輯是沒法重用的。
雖然 MVC 中的 View 的確「能夠」訪問 Model，
可是咱們不建議在 View 中依賴 Model，而是要求儘量把全部業務邏輯都放在 Controller 中處理，而 View 只和 Controller 交互。
問題解決方式
在MVP裏，Presenter徹底把Model和View進行了分離，主要的程序邏輯在Presenter裏實現。並且，Presenter與具體的View是沒有直接關聯的，而是經過定義好的接口進行交互，從而使得在變動View時候能夠保持Presenter的不變，即重用！ 不只如此，咱們還能夠編寫測試用的View，模擬用戶的各類操做，從而實現對Presenter的測試--而不須要使用自動化的測試工具。 咱們甚至能夠在Model和View都沒有完成時候，就能夠經過編寫Mock Object（即實現了Model和View的接口，但沒有具體的內容的）來測試Presenter的邏輯。 在MVP裏，應用程序的邏輯主要在Presenter裏實現，其中的View是很薄的一層。所以就有人提出了Presenter First的設計模式，就是根據User Story來首先設計和開發Presenter。在這個過程當中，View是很簡單的，可以把信息顯示清楚就能夠了。在後面，根據須要再隨便更改View，而對Presenter沒有任何的影響了。 若是要實現的UI比較複雜，並且相關的顯示邏輯還跟Model有關係，就能夠在View和Presenter之間放置一個Adapter。由這個 Adapter來訪問Model和View，避免二者之間的關聯。而同時，由於Adapter實現了View的接口，從而能夠保證與Presenter之間接口的不變。這樣就能夠保證View和Presenter之間接口的簡潔，又不失去UI的靈活性。 在MVP模式裏，View只應該有簡單的Set/Get的方法，用戶輸入和設置界面顯示的內容，除此就不該該有更多的內容，毫不允許直接訪問Model--這就是與MVC很大的不一樣之處。
優勢
一、模型與視圖徹底分離，咱們能夠
修改視圖而不影響模型
二、能夠
更高效地使用模型，由於全部的交互都發生在一個地方——Presenter內部
三、咱們能夠將
一個Presenter用於多個視圖，而不須要改變Presenter的邏輯。這個特性很是的有用，由於視圖的變化老是比模型的變化頻繁。
四、若是咱們把邏輯放在Presenter中，那麼咱們就能夠
脫離用戶接口來測試這些邏輯（單元測試）
缺點
因爲對視圖的渲染放在了Presenter中，
因此視圖和Presenter的交互會過於頻繁。還有一點須要明白，若是Presenter過多地渲染了視圖，每每會使得它與特定的視圖的聯繫過於緊密。
一旦視圖須要變動，那麼Presenter也須要變動了。好比說，本來用來呈現Html的Presenter如今也須要用於呈現Pdf了，那麼視圖頗有可能也須要變動。
二、
| 2.返回頂部 |
| 3.返回頂部 |
| 4.返回頂部 |
| 5.返回頂部 |
一、
二、
| 6.返回頂部 |
|
做者：ylbtech 出處：http://ylbtech.cnblogs.com/ 本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。 |
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。