【文章內(nèi)容簡介】 MVC （ ModelViewController）模式了。從 Smalltalk 時代開始， MVC 便被用來創(chuàng)建用戶界面。在 MVC 模式里，共包含三種類型的對象，模型 Model 是應用對象，視圖 View 用于向用戶展示，而控制器 Controller 定義了 View 對于用戶輸入的響應方式。不使用 MVC 時，用戶界面設計往往將這些對象混雜在一起，不利于提供設計的靈活性和復用性。 MVC 通過同時使用觀察者模式和 策略模式分離視圖和模型，同時提供對不同 UI 邏輯的支持。同時建立一個“訂閱 /通知”協(xié)議，視圖和模型彼 此分離。視圖必須保證它的顯示正確地反映了模型的狀態(tài)。一定模型發(fā)送了變化，它也將通知視圖，從而，視圖可以以此作為契機，更新對應的 UI 。 模型的變更傳播機制確保應用程序的數(shù)據(jù)發(fā)生變化時，所有的觀察者將在正確的時間得到通知。這讓所有依賴于模型的視圖和控制器得以同步。 這種方法 還 可以讓你為一個模型提供不同的多個視圖的表現(xiàn)形式，為能夠為一個模型創(chuàng)建新的視圖而無需重寫模型。 在運行階段，可同時打開多個視圖（共享一個 model），還可以動態(tài)地打開和關閉視圖。 圖 MVC 模式 8 而對于 View 和 Controller， 則是策略模式的一個例子。一個策略表示一個算法族的一個對象。通過定義一個算法族，我們可以動態(tài)或靜態(tài)地替換對應的策略。而策略的使用者 —— 這里的視圖，則完全不受影響。 通過將模型、視圖和控制器分離，可更換模型的視圖和控制器，甚至在運行階段都可以替換用戶界面。 但是，對于當今的移動開發(fā)， MVC 模式又有一些顯著的不足。首先， MVC 三個組件存在著一個環(huán)狀的依賴關系 。也就是說，一個組件接口的變化，必將同時影響另外兩個組件。不僅如此，環(huán)狀依賴也提高了單元測試的難度。同一時間，如果我們想對一個組件進行測試，必 須提供兩個 mock 對象。 此外，視圖和控制器的關系過于緊密?？刂破骱鸵晥D雖然分開了，但關系緊密，這導致無法分別重用它們。不僅如此，視圖和控制器與模型也是緊耦合的。視圖和控制器都直接調(diào)用模型，這意味著修改模型的接口將破壞視圖和控制器的代碼。 一種變體 —— MVP 模式 由于上述 MVC 模式的一系列問題，加之其誘人的優(yōu)點，于是， 便 有了它的一個變體 —— MVP 模式。 MVP 作為一個面向用戶界面設計的架構模式，被刻意設計，以充分利用一些自動化單元測試工具并且改善表現(xiàn)邏輯分離的問題。 圖 MVP 模式 在 MVP 模式中，模型 Model 組件提供了一個定義用于展示的數(shù)據(jù)的接口，并根據(jù)用戶的動作做出相應的處理邏輯。這里的 Model 和 MVC 中的 Model 并沒有什么差異。9 而表現(xiàn)者 Presenter 則 作為一個中間人的角色而存在，所有的表現(xiàn)邏輯都存在于表現(xiàn)者Presenter 中。 它從 Model 中取得數(shù)據(jù)，并對它進行格式化，然后在 View 中展示。所以， Presenter 也因此有了另一個名稱 —— 超級控制器。對于最后的 View 組件，這里我們稱它為被動視圖。視圖并不主動處理 UI 的更新和用戶動 作，它所做的，就是非常單一的功能 —— 展示用戶界面。視圖的更新由 Presenter 復制，對于用戶的動作，它也是直接轉發(fā)至 Presenter 中。 實際上，對于視圖所處理的邏輯的多少，每個不同的實現(xiàn)都不盡相同。在一個極端，視圖是一個完全的被動式的存在，將所有的用戶操作都轉發(fā)至 Presenter 中。 在這種情況下，當用戶觸發(fā) View 組件的一個事件回調(diào)時，它不會做任何的處理，而僅僅是調(diào)用presenter 的一個沒有參數(shù)也沒有返回值的方法。然后， Presenter 通過 View 組件的接口，取出必需的數(shù)據(jù)。最 后， Presenter 操作 Model 組件，得到結果后又相應地更新 UI。 而在另一方面，某些實現(xiàn)卻運行 View 組件處理某些特定的事件、操作或命令。這通常更適用于基于 web 的架構，這種情況下， View 組件通常運行在用戶的瀏覽器中，所以，對于一些交互命令， View 組件是一個更好的處理場所。 MVP 模式與 MVC 模式最大的不同在于， MVP 并不存在環(huán)狀依賴，取而代之，MVP 是鏈狀的依賴關系。這使得 MVP 更加地適合于單元測試。同時，由于 Presenter 的存在，即便 Model 的接口發(fā)生變化 ，我們也只需要修改 Presenter —— 我們的 View 組件，依然可以繼續(xù)使用而不需要做任何的修改。而對于 MVC 的優(yōu)點，在這里也同樣保持著。我們的 UI 和邏輯是顯著分離的，組件也可以復用。如果交換邏輯需要作出修改，也可以通過替換 Presenter 這個組件而得到所需的效果。同時，這里的 Presenter 也是作為一個策略而存在的，這意味著，我們可以在運行時動態(tài)地更換表現(xiàn)邏輯。 遺憾的是， MVP 也有其缺點。前面我們說 MVP 是鏈狀依賴的時候，敏銳的你就應該意識到，我們的調(diào)用鏈過長了。即使是 Model 中的一個小小的改變，也要跨過千山萬水才能夠表現(xiàn)在 UI 上。也就是說，與 MVC 相比，對于性能很關心的應用，這個模式可能就不太適用了。所幸的是，這種情況發(fā)生的幾率實在太低，所以一般不會是太大的問題。而更為致命的是，作為超級控制器的 Presenter， 對于 UI 的所有更新都要經(jīng)手的它，實現(xiàn)中往往存在很多的盲轉發(fā)。大多數(shù)時候，我們根本不需要對數(shù)據(jù)進行格式化，只是從 Model 取出，然后直接應用于 View 組件的更新。編寫這么 多的 盲轉發(fā)代碼，可不會是一件愉快的事。 10 更進一步 —— MVVM 模式 前面 我們提到 MVP 模式中，將數(shù)據(jù)顯示到 View 組件通常是一件比較無趣而繁瑣的工作。而 MVVM（ ModelViewViewModel） 的出現(xiàn)，就是為了解決這么一個問題。MVVM 同樣是對圖形用戶界面與應用邏輯的分離。它通過一種標記語言或 GUI 代碼，將 UI 與商業(yè)邏輯或后臺邏輯分離開。 MVVM 中的 View Model 組件是一個值轉換器；這意味著 View Model 的職責是從將 Model 類得來的數(shù)據(jù)對象進行轉化，使之更易于管理和表現(xiàn)。從這一點看， View Model 比 View 組件更加的模型化 ，并處理著幾乎所有的視圖表現(xiàn)邏輯。 View Model 可以使用中間人模式進行實現(xiàn)，它處理 View 所支持的所有 對后端邏輯的訪問 控制。 ModelViewViewModel 也叫 ModelViewBinder， 因為對 View 組件的更新，我們通常通過一些自動化的工具進行，也就是所謂的 data binding。 圖 MVVM 模式 從組件的依賴關系上看， MVVM 和 MVP 非常地相似，唯一的不同是， MVP 里，我們程序員自己手動執(zhí)行了一個所謂 data binding 的動作。 Model 組件也叫 domain model ，與 MVC 和 MVP 中的 Model 一樣，這里用于表現(xiàn)業(yè)務邏輯，并提供應用數(shù)據(jù)的存取。 View 組件也是，作為一個用戶界面而存在。 View Model 是 View 組件的一個抽象表示，用于暴露其公開的接口。與 MVC 中的 Controller 和 MVP 中的 Presenter 不同的是， MVVP 有一個 binder。 在 View Model 中， binder 調(diào)節(jié) 著 View 和 View Model 的通信。聲明式的對數(shù)據(jù)、命令和 UI 的綁定在 MVVM 模式中是隱式的。 Binder 將開發(fā)者從手工編寫大量模板代碼解放出來。 11 毫無例外， MVVM 也有其缺點。對簡單的應用而已，這樣的框架無意過于的厚重。而對于復雜的交互邏輯，靠程序 （ binder） 進行自動的數(shù)據(jù)綁定又顯得過于的力不從心。使用 MVVM 時，我們得自行拿捏一個中庸之道。 回歸簡樸 —— DocumentView 模式 MVC 存在著環(huán)狀依賴， MVP 調(diào)用鏈過長， MVVM 對簡單應用過于復雜，對復雜應用支持又不足，那么，我們又應該選擇哪一個模式呢？ 回想前面我們討論過的問題，我們需要的是 UI 和邏輯分離，需要它足 夠的輕量，并具有相當?shù)目蓴U展性。它只解決最為迫切，一直重復發(fā)生著的問題。那么，這樣的架構模式存不存在呢？答案是，存在，它就是所謂的 DocumentView 模式。 圖 DocumentView 模式 DocumentView 也是屬于 MVC 變體的一種。這里的 View ，和 MVC 中的 View并沒有什么顯著的差別， 同樣的用于向用戶展示信息和提供交互。而 Document 則相當于 Model 和 Controller 的結合，或者說， MVP 模式中的 Model 和 Presenter。 使用 DocumentView 模式的最為著名的架構，應該就屬微軟的 MFC 框架了。默認情況下， MFC 的項目生成向導會生成兩個類 —— Document 類和 View 類。 Document 負責管理數(shù)據(jù)并更新 View， View 組件則用于向用戶展示數(shù)據(jù)和提供交互功能。這就是我們所需要的最基本的 UI 和應用邏輯分離。 但是，如果僅僅是 UI 和邏輯分離，并不足以使我們選擇這么一個架構。選擇DocumentView， 還有著更多的理由。 對于絕大多數(shù)的 Android 應用，一個 Model 僅僅對應一個 View， 我們并沒有不需要 MVC 同步更新多個 View 組件的功能。如果使用 MVC， 卻要因此忍受它帶來的環(huán)狀依賴?？梢哉f， MVC 并不適用于 Android 應用的開發(fā)。 MVP 有著過長的調(diào)用鏈，無論是從 View 到 Model 還是從 Model 到 View, 我們不12 想要這些額外的消耗。對于性能非常重要的應用而已，中間的 Presenter 是不能忍受的。此外，很多時候，中間的 Presenter 并沒有做太大有用的工作，它只是單純地將View 和 Model 的調(diào)用相互轉發(fā)而已。 對于 MVVM， 不使用他的原因和上面 所述的它的缺點一樣。在簡單的應用表現(xiàn)不佳，復雜的應用卻有力不從心。 最為重要的一點是，由于它們都是基于 UI 和邏輯分離的原則所設計的，四個模式都有其共通的地方。而對于最簡單的 DocumentView， 它提供了最為基本的 UI 分離的支持，使用它，在合適的場合，我們可以輕易對它進行擴展，以增強為其他模式。 假定我們現(xiàn)在的 UI 交換邏輯過于的復雜， DocumentView 已經(jīng)無法滿足我們的需求。此時，我們可以對 DocumentView 進行擴展，使之成為一個 MVP 模 式。需要注意的一點是，盡管此時已經(jīng)變化為 MVP 模式，但我們還是重用了低層 DocumentView 框架的實現(xiàn)。 圖 將 DocumentView 擴展為 MVP 模式 增強的 DocumentView 在前面我們描述模式的時候，我們通常都只是說“ View”，“ Model” 等等。即便我們使用這樣的術語，但是，這并不意味著，各個組件是在和實體的類進行交談。這里“ View”， 并不特指某個具體的實現(xiàn)，它完全可以是一個接口。 目前 Android 的 Native 應用主要是使用 Java 進行 開發(fā)的，利用 Java 的語言特性，我們完全可以做得更好。 13 圖 增強的 DocumentView 這里的 I 指的是 Interface， 并且，這里的 interface 并不指一般意義上的接口，而是指 Java 語言的一個語法“ interface”。 組件并不互相直接就進行通信，而是通過引用一句接口。通過針對接口進行編程，我們保留了對組件進行透明替換的能力。 雙方通過接口進行引用， 使得在利用對方提供的接口時 ，只能使用接口所提供的抽象，這大大減少了需要同時關注的問題，很好地隔離了復雜度。 接口提供了一 個語言級的支持，可以實現(xiàn)安全、透明的實現(xiàn)替換。我們并不關心 View 和 Document 的實際類型是什么，我們只知道，那個類實現(xiàn)了我們所需的接口。只有實現(xiàn)對應的接口，我們就可以對一個組件進行直接的替換，而另一個組件則完全不用更改。甚至，與 MVC、 MVP 等提供的動態(tài)性一樣，我們也可以在運行時動態(tài)地選擇 View 和 Document 的實現(xiàn)。 定義接口的過程中，可以迫使我們對組件所需要提供的功能進行細致的考慮。通過對業(yè)務進行分析并制定接口，可以避免在尚不清楚邏輯的情況下過快地進行編程。同時，它也可以幫助我們理 清應用的邏輯。還應注意的是，接