# 為什么需要架構 通過設計使程序模塊化，做到模塊內部的高聚合和模塊之間的低耦合。這樣做的好處是使得程序在開發的過程中，開發人員只需要專注于一點，提高程序開發的效率，并且更容易進行后續的測試以及定位問題。但設計不能違背目的，對于不同量級的工程，具體架構的實現方式必然是不同的，切忌犯為了設計而設計，為了架構而架構的毛病。 ## MVC *View：對應于布局文件* *Model：業務邏輯和實體模型* *Controllor：對應于Activity* 在Android開發中，Activity并不是一個標準的MVC模式中的Controller，它的首要職責是加載應用的布局和初始化用戶界面，并接受并處理來自用戶的操作請求，進而作出響應。隨著界面及其邏輯的復雜度不斷提升，Activity類的職責不斷增加，以致變得龐大臃腫。 ## MVP *View 對應于Activity，負責View的繪制以及與用戶交互* *Model 依然是業務邏輯和實體模型* *Presenter 負責完成View于Model間的交互* 在MVP里，Presenter完全把Model和View進行了分離，主要的程序邏輯在Presenter里實現。而且，Presenter與具體的View是沒有直接關聯的，而是通過定義好的接口進行交互，從而使得在變更View時候可以保持Presenter的不變。 View只應該有簡單的Set/Get的方法，用戶輸入和設置界面顯示的內容，除此就不應該有更多的內容，絕不容許直接訪問Model，這就是與MVC很大的不同之處。 #### MVP的優缺點 ##### 優點 降低耦合度，實現了Model和View真正的完全分離。 模塊職責劃分明顯，層次清晰。 Presenter可以復用，一個Presenter可以用于多個View，而不需要更改Presenter的邏輯（當然是在View的改動不影響業務邏輯的前提下）。 如果我們把邏輯放在Presenter中，那么我們就可以脫離用戶接口來測試這些邏輯（單元測試）。 ##### 缺點 額外的代碼復雜度及學習成本。 如果Presenter過多地與特定的視圖的聯系過于緊密，一旦視圖需要變更，那么Presenter也需要變更了。 ## MVVM MVVM可以算是MVP的升級版， 其中的VM是ViewModel的縮寫，ViewModel可以理解成是View的數據模型和Presenter的合體，ViewModel和View之間的交互通過Data Binding完成， 而Data Binding可以實現雙向的交互，這就使得視圖和控制層之間的耦合程度進一步降低，關注點分離更為徹底，同時減輕了Activity的壓力。  ### MVC->MVP->MVVM演進過程 MVC -> MVP -> MVVM 這幾個軟件設計模式是一步步演化發展的，MVVM 是從 MVP 的進一步發展與規范，MVP 隔離了MVC中的 M 與 V 的直接聯系后，靠 Presenter 來中轉，所以使用 MVP 時 P 是直接調用 View 的接口來實現對視圖的操作的，這個 View 接口的東西一般來說是 showData、showLoading等等。M 與 V已經隔離了，方便測試了，但代碼還不夠優雅簡潔，所以 MVVM 就彌補了這些缺陷。在 MVVM 中就出現的 Data Binding 這個概念，意思就是 View 接口的 showData 這些實現方法可以不寫了，通過 Binding 來實現。 ## 同 三者的差異在于如何粘合View和Model，實現用戶的交互操作以及變更通知 如果把這三者放在一起比較，先說一下三者的共同點，也就是Model和View： #### Model： 數據對象，同時，提供本應用外部對應用程序數據的操作的接口，也可能在數據變化時發出變更通知。Model不依賴于View的實現，只要外部程序調用Model的接口就能夠實現對數據的增刪改查。 #### View： UI層，提供對最終用戶的交互操作功能，包括UI展現代碼及一些相關的界面邏輯代碼。 ## 異 #### Controller Controller接收View的操作事件，根據事件不同，或者調用Model的接口進行數據操作，或者進行View的跳轉，從而也意味著一個Controller可以對應多個View。Controller對View的實現不太關心，只會被動地接收，Model的數據變更不通過Controller直接通知View，通常View采用觀察者模式監聽Model的變化。 #### Presenter Presenter與Controller一樣，接收View的命令，對Model進行操作；與Controller不同的是Presenter會反作用于View，Model的變更通知首先被Presenter獲得，然后Presenter再去更新View。一個Presenter只對應于一個View。根據Presenter和View對邏輯代碼分擔的程度不同，這種模式又有兩種情況：Passive View和Supervisor Controller。 #### ViewModel 注意這里的“Model”指的是View的Model，跟MVVM中的一個Model不是一回事。所謂View的Model就是包含View的一些數據屬性和操作的這么一個東東，這種模式的關鍵技術就是數據綁定（data binding），View的變化會直接影響ViewModel，ViewModel的變化或者內容也會直接體現在View上。這種模式實際上是框架替應用開發者做了一些工作，開發者只需要較少的代碼就能實現比較復雜的交互。