前言

MVC、MVP、MVVM是當下Android開發(fā)中主要的項目架構(gòu)，當你開發(fā)一個app時，合理的軟件架構(gòu)有利于后期的維護。Android開發(fā)中我們可以選擇的架構(gòu)只有以上三種，三種架構(gòu)各有優(yōu)缺點，我們可以從中選擇最合適我們的架構(gòu)。

MVC

MVC（Model-View-Controller）是最常見的軟件架構(gòu)之一，也是我們剛開始做Android開發(fā)選用的架構(gòu)。

數(shù)據(jù)關(guān)系為：

• View接收用戶交互指令
• View將指令傳遞給Controller
• Controller執(zhí)行相關(guān)的業(yè)務(wù)邏輯，并操作Model進行數(shù)據(jù)更新
• Control更新數(shù)據(jù)完畢后，Model通知View更新數(shù)據(jù)變化
• View更新數(shù)據(jù)，更新界面

在Android中

那么具體到Android項目中呢？我們知道在一個Android項目中，有java目錄下的class文件，也有res目錄下的各種資源，layout里面的xml文件就對應(yīng)于MVC的view層，里面都是一些view的布局代碼。而各種java bean，還有就對應(yīng)于model層，至于controller層嘛，當然就是各種activity或者Fragment了。

• 通俗一點說，比如你按下了界面上的一個Button，Button是在xml里進行布局的，所以接收交互響應(yīng)的是在View里，你按下Button的反應(yīng)，比如網(wǎng)絡(luò)請求，HttpHelper類就是Model了，那怎么連接這兩層呢，我們是通過btn.setOnClickListener()連接的，這個是寫在Activity里面的，既是在Controller層了。
• 這里還要補充一點，Model進行數(shù)據(jù)更新完畢后，通知View進行數(shù)據(jù)更新，一般來說是通過觀察者模式進行更新的。在上面的三角關(guān)系中，一個Model可能對應(yīng)著多個View，通過觀察者，所有注冊的View都能接收到更新。例如，在我們在使用ListView的時候，更新數(shù)據(jù)是通過Adapter的notifyDataSetChanged()方法進行數(shù)據(jù)更新，如果你跟進BaseAdapter的代碼，你就會發(fā)現(xiàn)，它還是通過觀察者模式更新數(shù)據(jù)。

public abstract class BaseAdapter implements ListAdapter, SpinnerAdapter {
//數(shù)據(jù)觀察者
    private final DataSetObservable mDataSetObservable = new DataSetObservable();

    public boolean hasStableIds() {
        return false;
    }
    
    public void registerDataSetObserver(DataSetObserver observer) {
        mDataSetObservable.registerObserver(observer);
    }

    public void unregisterDataSetObserver(DataSetObserver observer) {
        mDataSetObservable.unregisterObserver(observer);
    }
    
    /**
     * Notifies the attached observers that the underlying data has been changed
     * and any View reflecting the data set should refresh itself.
     */
    public void notifyDataSetChanged() {
        mDataSetObservable.notifyChanged();
    }
}

缺點

在Android開發(fā)中，MVC大家肯定會用，但是這種模式有什么區(qū)缺點嗎，肯定是有的，要不然也不會有后來的MVP、MVVM了不是。大家可以想想，xml作為View層，控制能力太弱了，比如我們要更換了背景，更換個字體顏色，xml中式無法完成的，你只能寫在Activity中，這樣就使得作為Controller層的Activity，也充當起了View的角色，最終結(jié)果使得Activity代碼過于臃腫，我在開發(fā)的過程中，稍微復(fù)雜一點的界面，Activity可以達到2000+行代碼，這樣的代碼維護起來相信誰都會感到頭痛吧。

MVP

MVP作為MVC模式的演化，解決了MVC模式的一些缺點。可以看到，View層和Model層不能直接進行通信了，轉(zhuǎn)而交給Presenter層作為中間的代理。其中Model層和MVC是一樣的，但是Activity和Fragment則是純粹的View層了，不再充當Controller的角色了。所有的交互事件交給Presenter層處理。

數(shù)據(jù)關(guān)系為

• View接收用戶交互請求
• View將請求提交給Presenter層
• Presenter層操作Model進行數(shù)據(jù)更新
• Model層通知Presenter層數(shù)據(jù)發(fā)生變化
• Presenter層操作View層界面更新
  這樣實際上將View層和Model層解耦了。
  在Android中
• 對于View，一般要有個IView的接口，Activity或者Fragment要實現(xiàn)這個接口。此接口主要是有關(guān)界面的操作，如下栗子中，獲取EditText的輸入值，顯示Toast，顯示和隱藏ProgressBar等。

public interface ILoginView {
        String getUserName();
        String getPassWord();
        void showToast(String content);
        void closeDispose(Disposable disposable);
        void showProgress();
        void hideProgress();
        void toOtherActivity();
    }
}

`
public class LoginActivity extends BaseActivity implements IView.ILoginView {}

• 對于Model，一般要有一個IModel，Model要繼承這個接口

public class IModel {
    public interface ILoginModel {
        void login(LoginBody loginBody, MyCallBack<UserLoginBean> callBack); //登錄
    }

}

public class LoginModel implements IModel.ILoginModel {}

MVVM

可以看到，和MVP比較，presenter層換成了viewmodel層，其實view層和viewmodel層是相互綁定的關(guān)系，這意味著當你更新viewmodel層的數(shù)據(jù)的時候，view層會相應(yīng)的變動ui。

數(shù)據(jù)關(guān)系：

• View接收交互請求
• View將請求提交給ViewModel
• ViewModel操作Model進行數(shù)據(jù)更新
• Model更新完數(shù)據(jù)，通知ViewModel數(shù)據(jù)發(fā)生變化
• View和ViewModel是雙向綁定的關(guān)系，ViewModel變化，View層會相應(yīng)變化

所以MVVM模式一般要結(jié)合Google推出的DataBinding，將View和ViewModel層進行數(shù)據(jù)綁定。

關(guān)于MVP和MVVM的例子，以后會給出。

最后

任何的項目框架，都是為項目服務(wù)的。沒有絕對的好壞之分，只有更合適的選擇。在項目進展的不同階段，做出最合適的調(diào)整，才是是更適合團隊項目發(fā)展的框架。