**mvp架構及開發模式首先，讓我們思考下為什麼在android開發中如此迫切地需要乙個清晰的架構。mvc or mvp pattern – whats the difference?
android中的mvp
【譯】android開發中的mvp架構
該段摘自「**大全第二版」
「避免建立神類。避免建立無所不知，無所不能的上帝類。如果乙個類需要花費時間從其他類中通過get()和set()檢索資料（也就是說，需要深入業務並且告訴它們如何去做），所以是否應該把這些功能函式更好的組織到其它類而不是上帝類中。（riel 1996）」
上帝類的維護成本很高，你很難理解正在進行的操作,並且難以測試和擴充套件,這就是為什麼要避免建立上帝類的**法則。
然而，在android開發中，如果你不考慮架構的話，activity類往往會越來越大。這是因為，在android中，允許view和其它執行緒共存於activity內。其實最大的問題莫過於在activity中同時存在業務邏輯和ui邏輯。這會增加測試和維護的成本。
mvp代表model，view和presenter。
* view層負責處理使用者事件和檢視部分的展示。在android中，它可能是activity或者fragment類。
* model層負責訪問資料。資料可以是遠端的server api，本地資料庫或者sharedpreference等。
* presenter層是連線（或適配）view和model的橋梁。
下圖是基於mvp架構的模式之一。view是ui執行緒。presenter是view與model之間的介面卡。usecase或者domain在model層中，負責從實體獲取或載入資料。依賴規則如下：
關鍵是，高層介面不知道底層介面的的細節，或者更準確地說，高層介面不能，不應該,並且必須不了解底層介面的細節，是（面向）抽象的，並且是細節隱藏。
同心圓將軟體劃分為不同的區域,一般的，隨著層級的深入，軟體的等級也就越高。外圓是實現機制，內圓是核心策略。
entities：
* 可以是乙個持有方法函式的物件
* 可以是一組資料結構或方法函式
* 它並不重要,能在專案中被不同應用程式使用即可
use cases
* 包含特定於應用程式的業務規則
* 精心編排流入entity或者entity流出的資料
* 指揮entity直接使用專案範圍內的業務規則,從而實現use case的目標
presenter，controllers
* 將use case和entity中的資料轉換成格式最方便的資料
* 外部系統，如資料庫或網頁能夠方便的使用這些資料
* 完全包含gui的mvc架構
external inte***ces，ui，db
* 所有的細節所在
* 如資料庫細節，web框架細節，等等
因此我們可以發現mvp的優點如下：
1. 模型與檢視完全分離，我們可以修改檢視而不影響模型
2. 可以更高效地使用模型，因為所有的互動都發生在乙個地方——presenter內部
3. 我們可以將乙個presenter用於多個檢視，而不需要改變presenter的邏輯。這個特性非常的有用，因為檢視的變化總是比模型的變化頻繁
4. 如果我們把邏輯放到presenter中，那麼我們就可以脫離使用者介面來測試這些邏輯（單元測試）。
mvvm可以算是mvp的公升級版，其中vm是viewmodel的縮寫，viewmodel可以理解成是view的資料模型和presenter的合體，viewmodel和view之間的監護通過data binding完成，而data binding可以實現雙向的互動，這就使得檢視和控制層之間的耦合程度進一步降低，關注點分離更為徹底，同時減輕了activity的壓力。
那麼，哪乙個才是最好的呢？哪乙個比其他的更優秀呢？我能只選擇乙個嗎？
答案是，no。
這些模式的動機都是一樣的。那就是如何避免複雜混亂的**，讓執行單元測試變得容易，創造高質量應用程式。就這樣。
當然，遠不止這三種架構模式。而且任何一種模式都不可能是銀彈，他們只是架構模式之一，不是解決問題的唯一途徑。這些只是方法、手段而不是目的、目標。
ok，讓我們回到mvp架構上。剛剛我們了解了什麼是mvp，討論了mvp以及其它熱門架構，並且介紹了mvc，mvp和mvvm三者間的不同。這是關於mvp架構利與弊的總結。
利
* 可測試（tdd）
* 可維護（**復用）
* 容易review
* 資訊遮蔽
弊* aop（aspect-oriented programming，面向切面程式設計）*
誕生於上個世紀90年代，是對oop（object-oriented programming，物件導向程式設計）的補充和完善。oop引入封裝、繼承和多型性等概念來建立一種物件層次結構，用以模擬公共行為的乙個集合。當我們需要為分散的物件引入公共行為的時候，oop則顯得無能為力。也就是說，oop允許你定義從上到下的關係，但並不適合定義從左到右的關係。例如日誌功能。日誌**往往水平地散布在所有物件層次中，而與它所散布到的物件的核心功能毫無關係。對於其他型別的**，如安全性、異常處理和透明的持續性也是如此。這種散布在各處的無關**被稱為橫切（cross-cutting）**，在oop設計中，它導致了大量**的重複，而不利於各個模組的重用。而aop技術則恰恰相反，它利用一種稱為「橫切」的技術，剖解開封裝的物件內部，並將哪些影響了多個類的公共行為封裝到乙個可重用模組，並將其命名為「aspect」，即方面。所謂「方面」，簡單地說，就是將那些與業務無關，卻為業務模組所共同呼叫的邏輯或責任封裝起來，便於減少系統的重複**，降低模組間的耦合度，並有利於未來的可操作性和可維護性。
aop在android中的使用
以太坊架構簡析
httpclient 支援http協議 實現get post等http方法。http json rpc ipc 1 實現程式 程序間的通訊。外部程式可以通過json rpc呼叫api。swarm 乙個web應用開發框架，其允許程式分布在多台計算機上，並能夠動態分配運算以提公升運算效率。容器 包含程式...
RAC架構演變簡析
rac架構演變簡析 從單例項到rac，體系結構也由rac集群和clusterware集群構建 sga的變化 www.2cto.com sga的顯著變化是多了乙個grd grd儲存 pcm lock資訊 節點健康狀態的bitmap 後台程序的變化 這裡只闡述rac集群上的後台程序的變化 lmon程序 ...
簡析三層架構
通過幾個問題，來初步的學習一下三層架構。1 什麼是三層架構 2 應用場景 為什麼要用三層架構？3 三層作用 4 各個層之間的關係 5 三層聯絡 引用 6 各層是怎樣呼叫的 7 三層和二層的對照 這幾個都是學習三層中最主要的問題，僅僅有把這些問題搞清楚。才算是開啟了三層的門。在軟體體系架構設計中，分層...