在android開發中，activity並不是乙個標準的mvc模式中的controller，它的首要職責是載入應用的布局和初始化使用者 介面，並接受並處理來自使用者的操作請求，進而作出響應。隨著介面及其邏輯的複雜度不斷提公升，activity類的職責不斷增加，以致變得龐大臃腫。
mvp從更早的mvc框架演變過來，與mvc有一定的相似性：controller/presenter負責邏輯的處理，model提供資料，view負責顯示。
mvp框架由3部分組成：view負責顯示，presenter負責邏輯處理，model提供資料。在mvp模式裡通常包含3個要素（加上view inte***ce是4個）：
當我們將activity複雜的邏輯處理移至另外的乙個類（presenter）中時，activity其實就是mvp模式中的view，它負責ui元素的初始化，建立ui元素與presenter的關聯（listener之類），同時自己也會處理一些簡單的邏輯（複雜的邏輯交由 presenter處理）。
兩種模式的主要區別：
因此我們可以發現mvp的優點如下：
1、模型與檢視完全分離，我們可以修改檢視而不影響模型；
2、可以更高效地使用模型，因為所有的互動都發生在乙個地方——presenter內部；
3、我們可以將乙個presenter用於多個檢視，而不需要改變presenter的邏輯。這個特性非常的有用，因為檢視的變化總是比模型的變化頻繁；
4、如果我們把邏輯放在presenter中，那麼我們就可以脫離使用者介面來測試這些邏輯（單元測試）。
轉移邏輯操作之後可能部分較為複雜的activity內**量還是不少，於是需要在分層的基礎上再加入模板方法（template method）。
模型層（model）中的整體**量是最大的，一般由大量的package組成，針對這部分需要做的就是在程式設計的過程中，做好模組的劃分，進行介面隔離，在內部進行分層。
強化presenter的作用，將所有邏輯操作都放在presenter內也容易造成presenter內的**量過大，對於這點，有乙個方法是在ui層和presenter之間設定中介者mediator，將例如資料校驗、組裝在內的輕量級邏輯操作放在mediator中；在presenter和model之間使用**proxy；通過上述兩者分擔一部分presenter的邏輯操作，但整體框架的控制權還是在presenter手中。mediator和proxy不是必須的，只在presenter負擔過大時才建議使用。
最終的架構如下圖所示：
大話MVP架構模式（1） Basic
mvp是使用者介面的架構模式，旨在促進自動化單元測試，並改善表達邏輯中的關注點分離 the separation of concerns 通常view的實現例項化具體的presenter物件，並向其 the presenter 提供自身 the view 的引用。下文中的c 演示了乙個簡單的view...
《企業應用架構模式》 分層
在系統的分層組織方式下，上層通過介面使用下層定義的各種服務，下層對上層一無所知。每一層都對自己的上層隱藏其下層的細節，因此第4層無需知道第2層的細節。分層的好處 1.可以專注理解某一層，無需過多了解其他層次 2.可以替換某層的具體實現，只要前後提供的服務 介面 相同即可 3.可以將層次間的依賴性減到...
接觸《企業應用架構模式》
國慶七天的長假，過得有些昏昏冉冉。那麼期待的長假，在狠狠飽睡幾天之後居然有點想上班了，唉，真是 j 啊 前天去南山新開業的書城，沒有找到 企業應用架構模式 martin fowler著 呵，今天早上在 china pub 上下了訂單，中午就收到書了。趕快看了前面幾章，真是暢快之極啊！雖然有些東西我也...