前言
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ù)關系為：
- View接收用戶交互指令
- View將指令傳遞給Controller
- Controller執(zhí)行相關的業(yè)務邏輯，并操作Model進行數(shù)據(jù)更新
- Control更新數(shù)據(jù)完畢后浓镜，Model通知View更新數(shù)據(jù)變化
- View更新數(shù)據(jù)溃列，更新界面
在Android中
那么具體到Android項目中呢？我們知道在一個Android項目中膛薛，有java目錄下的class文件听隐，也有res目錄下的各種資源，layout里面的xml文件就對應于MVC的view層相叁，里面都是一些view的布局代碼遵绰。而各種java bean，還有就對應于model層增淹，至于controller層嘛椿访，當然就是各種activity或者Fragment了。
- 通俗一點說虑润，比如你按下了界面上的一個Button成玫，Button是在xml里進行布局的，所以接收交互響應的是在View里拳喻，你按下Button的反應哭当，比如網(wǎng)絡請求，HttpHelper類就是Model了冗澈，那怎么連接這兩層呢钦勘，我們是通過btn.setOnClickListener()連接的，這個是寫在Activity里面的亚亲，既是在Controller層了彻采。
- 這里還要補充一點，Model進行數(shù)據(jù)更新完畢后捌归，通知View進行數(shù)據(jù)更新肛响，一般來說是通過觀察者模式進行更新的。在上面的三角關系中惜索，一個Model可能對應著多個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ā)的過程中，稍微復雜一點的界面掸犬，Activity可以達到2000+行代碼袜漩，這樣的代碼維護起來相信誰都會感到頭痛吧。
MVP
MVP作為MVC模式的演化湾碎，解決了MVC模式的一些缺點宙攻。可以看到介褥，View層和Model層不能直接進行通信了座掘，轉(zhuǎn)而交給Presenter層作為中間的代理。其中Model層和MVC是一樣的呻顽，但是Activity和Fragment則是純粹的View層了雹顺，不再充當Controller的角色了。所有的交互事件交給Presenter層處理廊遍。
數(shù)據(jù)關系為
- View接收用戶交互請求
- View將請求提交給Presenter層
- Presenter層操作Model進行數(shù)據(jù)更新
- Model層通知Presenter層數(shù)據(jù)發(fā)生變化
- Presenter層操作View層界面更新
這樣實際上將View層和Model層解耦了嬉愧。
在Android中 - 對于View，一般要有個IView的接口喉前，Activity或者Fragment要實現(xià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層是相互綁定的關系，這意味著當你更新viewmodel層的數(shù)據(jù)的時候视事，view層會相應的變動ui胆萧。
數(shù)據(jù)關系：
- View接收交互請求
- View將請求提交給ViewModel
- ViewModel操作Model進行數(shù)據(jù)更新
- Model更新完數(shù)據(jù)，通知ViewModel數(shù)據(jù)發(fā)生變化
- View和ViewModel是雙向綁定的關系俐东，ViewModel變化跌穗，View層會相應變化
所以MVVM模式一般要結(jié)合Google推出的DataBinding，將View和ViewModel層進行數(shù)據(jù)綁定虏辫。
關于MVP和MVVM的例子蚌吸，以后會給出。
最后
任何的項目框架砌庄，都是為項目服務的套利。沒有絕對的好壞之分，只有更合適的選擇鹤耍。在項目進展的不同階段肉迫，做出最合適的調(diào)整，才是是更適合團隊項目發(fā)展的框架稿黄。
