軟件架構之--MVC、MVP、MVVM

MVC

簡介

MVC全名是Model View Controller，是 模型(model)－視圖(view)－控制器(controller) 的縮寫，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯聚集到一個部件裏面，在改進和個性化定製界面及用戶交互的同時，不需要重新編寫業務邏輯。
在很長的一段時間MVC被用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。在Android中，Activity的角色寬泛的說就是Controller(實際上在MVC中很難區分Activity到底應該處於V還是C的角色，因爲activity即包含了界面也包含了一部分邏輯處理)，xml佈局就是 View 層的表現，而網絡請求的數據或者數據庫表現爲 Model 層。

簡單概括就是：

項目	說明
View（視圖層）	用戶界面
Controller（控制層）	業務邏輯
Model（數據層）	數據保存

圖示關係

下圖表達出了三者之間的關係：
View 傳送指令到 Controller
Controller 完成業務邏輯後，要求 Model 改變狀態
Model 將新的數據發送到 View，用戶得到反饋

可以看到，在MVC模型裏，Model不依賴於View，但是View是依賴於Model，這就避免不了我們會在View裏面有業務邏輯，當複用和擴展的時候由於有業務邏輯的參與，改動變得困難，比方說我們經常在點擊事件中處理網絡訪問，將拿到的數據在更新UI，就會發現界面展示層做的東西除了自身UI外還有其他自己不應該關心的事情。我們始終的宗旨是：各司其職，互相隔離。

//View和Model耦合舉例
public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        
        findViewById(R.id.main_btn).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
               //1.接口請求數據
               //2.更新UI
            }
        });
    }


}

優缺點

優點

1. 耦合度較低
   視圖層和業務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的業務流程或者業務規則的改變只需要改動MVC的模型層即可。因爲模型與控制器和視圖相分離，所以很容易改變應用程序的數據層和業務規則。¹
2. 重用度高
   MVC模式允許使用各種不同樣式的視圖來訪問同一個服務器端的代碼，因爲多個視圖能共享一個模型，它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，用戶可以通過電腦也可通過手機來訂購某樣產品，雖然訂購的方式不一樣，但處理訂購產品的方式是一樣的。由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同的界面使用。例如，很多數據可能用HTML來表示，但是也有可能用WAP來表示，而這些表示所需要的命令是改變視圖層的實現方式，而控制層和模型層無需做任何改變。由於已經將數據和業務規則從表示層分開，所以可以最大化的重用代碼了。模型也有狀態管理和數據持久性處理的功能，例如，基於會話的購物車和電子商務過程也能被Flash網站或者無線聯網的應用程序所重用。¹
3. 成本低
   MVC使開發和維護用戶接口的技術含量降低。¹
4. 部署快
   使用MVC模式使開發時間得到相當大的縮減，它使程序員（Java開發人員）集中精力於業務邏輯，界面程序員（HTML和JSP開發人員）集中精力於表現形式上。 ¹

缺點

1. 沒有明確的定義
   完全理解MVC並不是很容易。使用MVC需要精心的計劃，由於它的內部原理比較複雜，所以需要花費一些時間去思考。同時由於模型和視圖要嚴格的分離，這樣也給調試應用程序帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。¹
2. 增加系統結構和實現的複雜性
   對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的複雜性，並可能產生過多的更新操作，降低運行效率。難以測試，必須手動點擊，使用各種自動化的測試工具。¹
3. 視圖與控制器間的過於緊密的連接
   視圖與控制器是相互分離，但卻是聯繫緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。¹
4. 視圖對模型數據的低效率訪問
   依據模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。¹
5. 一般高級的界面工具或構造器不支持模式
   改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，會造成MVC使用的困難。¹
6. 代碼難以重用。
   UI是很難重用，因爲要求總是不同。所以，導致重複的代碼四處都是，維護麻煩。

應用場景

交互簡單的小型應用程序

MVP

簡介

MVP（Model View Presenter）則是對MVC的進一步改造，MVP的出現就是爲進一步分離業務邏輯和界面處理。在MVP中，M與V完全切斷聯繫，由P進行總控。當V接收到了操作，將相應的請求傳遞到P，由P進行業務處理以及與M進行交互，同時P又在恰當的時機對view進行更新（接口 / 回調方法 / 事件）。這樣V只需要暴露出接口，V與P通過接口通訊，一方面能夠將業務邏輯轉移至P，一方面通過接口使得P可以適配多個V。

圖示關係

在MVP裏，Presenter完全把Model和View進行了分離，主要的程序邏輯在 Presenter裏實現。而且，Presenter與具體的View是沒有直接關聯的，而是通過定義好的接口進行交互，從而使得在變更View時候可以保持Presenter的不變，即重用！

不僅如此，我們還可以編寫測試用的View，模擬用戶的各種操作，從而實現對Presenter的測試–而不需要使用自動化的測試工具。

我們甚至可以在Model和View都沒有完成時候，就可以通過編寫Mock Object（即實現了Model和View的接口，但沒有具體的內容的）來測試Presenter的邏輯。

在MVP裏，應用程序的邏輯主要在Presenter來實現，其中的View是很薄的一層。 因此就有人提出了Presenter First的設計模式，就是根據User Story來首先設計和開發Presenter。在這個過程中，View是很簡單的，能夠把信息顯示清楚就可以了。在後面，根據需要再隨便更改View， 而對Presenter沒有任何的影響了。

如果要實現的UI比較複雜，而且相關的顯示邏輯還跟Model有關係，就可以在View和 Presenter之間放置一個Adapter。由這個 Adapter來訪問Model和View，避免兩者之間的關聯。而同時，因爲Adapter實現了View的接口，從而可以保證與Presenter之 間接口的不變。這樣就可以保證View和Presenter之間接口的簡潔，又不失去UI的靈活性。 ²

在MVP模式裏，View只應該有簡單的Set/Get的方法，用戶用戶輸入和設置界面顯示的內容，除此就不應該有更多的內容，絕不容許直接直接訪問Model–這就是與MVC很大的不同之處。

Demo

這個是簡單的例子：
MVP demo

MVVM

---

1. https://www.jianshu.com/p/ff6de219f988.html ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

2. https://www.cnblogs.com/xianshui/p/8469158.html ↩︎