1. 程式人生 > >Android UI層的三種框架模式-MVC、MVP、MVVM

Android UI層的三種框架模式-MVC、MVP、MVVM

MVC

MVC全名是Model View Controller,是模型(model)-檢視(view)-控制器(controller)的縮寫。

呼叫關係


資料關係

  • View 接受使用者互動請求
  • View 將請求轉交給Controller
  • Controller 操作Model進行資料更新
  • 資料更新之後,Model通知View更新資料變化
  • View 更新變化資料

Android實現

對於原生的Android應用,MVC的角色分配如下:

View :layout裡面的xml佈局檔案

Model:各種Java bean,一些類似repository類 等

Controller:各種Activity


缺點:

xml作為view層,控制能力實在太弱了,你想去動態的改變一個頁面的背景,或者動態的隱藏/顯示一個按鈕,這些都沒辦法在xml中做,只能把程式碼寫在activity中,造成了activity既是controller層,又是view層的這樣一個窘境。如果是一個邏輯很複雜的頁面,activity或者fragment動輒上千行呢?這樣不僅寫起來麻煩,維護起來更是噩夢。

MVC還有一個重要的缺陷,View層和Model層是相互可知的,這意味著兩層之間存在耦合,耦合對於一個大型程式來說是非常致命的,因為這表示開發,測試,維護都需要花大量的精力。

正因為MVC有這樣那樣的缺點,所以才演化出了MVP和MVVM這兩種框架。

MVP MVP的全稱為Model-View-Presenter,Model提供資料,View負責顯示,Controller/Presenter負責邏輯的處理。
MVP作為MVC的演化,解決了MVC不少的缺點,對於Android 來說,MVP的Model 層相對於 MVC 是一樣的,而 Activity 和Fragment 不再是 Controller 層,而是純粹的 View 層,所有關於使用者事件的轉發全部交由 Presenter 層處理。下面還是讓我們看圖

從圖中就可以看出,最明顯的差別就是 View 層和 Model 層不再相互可知,完全的解耦,取而代之的 Presenter 層充當了橋樑的作用,用於操作 View 層發出的事件傳遞到 Presenter 層中, Presenter 層去操作 Model 層,並且將資料返回給 View 層,整個過程中 View 層和 Model 層完全沒有聯絡。看到這裡大家可能會問,雖然 View 層和 Model 層解耦了,但是 View 層和 Presenter 層不是耦合在一起了嗎?其實不是的,對於 View 層和 Presenter 層的通訊,我們是可以通過介面實現的,具體的意思就是說我們的Activity ,Fragment 可以去實現實現定義好的介面,而在對應的 Presenter 中通過介面呼叫方法。不僅如此,我們還可以編寫測試用的View,模擬使用者的各種操作,從而實現對Presenter的測試。這就解決了MVC模式中測試,維護難的問題。


當然,其實最好的方式是使用 Fragment 作為 View 層,而 Activity 則是用於建立 View 層( Fragment )和 Presenter 層(Presenter)的一個控制器。


MVVM

MVVM是Model-View-ViewModel的簡寫。最早是由微軟提出的。


從圖中看出,它和MVP的區別貌似不大,只不過是 Presenter 層換成了 ViewModel 層,還有一點就是 View 層和 ViewModel 層是相互繫結的關係,這意味著當你更新 ViewModel 層的資料的時候,View 層會相應的變動UI。


我們很難去說MVP和MVVM這兩個MVC的變種孰優孰劣,還是要具體情況具體分析。

參考:http://blog.csdn.net/jdsjlzx/article/details/51174396