資訊專欄INFORMATION COLUMN
摘要：架構(gòu)的特點與局限架構(gòu)的特點是面向接口編程。架構(gòu)的特點和不足為解決職能邊界不明確的問題，在架構(gòu)中，業(yè)務(wù)邏輯的職能被轉(zhuǎn)移到領(lǐng)域?qū)樱蓪Ｂ毠芾怼５淖饔檬且曈X交互，為此的職責(zé)范圍是請求數(shù)據(jù)和處理邏輯。
聲明轉(zhuǎn)載于作者：KunMinX
原文鏈接：https://www.jianshu.com/p/9ef...
前不久剛結(jié)束對 20 模塊項目的第 3 輪重構(gòu)，一路見證 MVC、MVP、Clean 的優(yōu)缺點并形成自己的體會。
近期在總結(jié)工作經(jīng)驗的同時，開始寫博客。順便開源了我設(shè)計的 ViaBus 架構(gòu)。
項目地址：項目常用架構(gòu)比對
https://github.com/KunMinX/an...
以下，對常見的 MVC、MVP、Clean、AAC 架構(gòu)做個比對。
首先，一張表格展示各架構(gòu)的類冗余情況：
需求是，寫三個頁面，ListFragment、DetailFragment、PreviewFragment，每個頁面至少用到 3個 Note 業(yè)務(wù)、3個 User 業(yè)務(wù)。問：上述架構(gòu)分別需編寫多少類？
| 架構(gòu) | 涉及類 | 類總數(shù) |
|---|---|---|
| MVC | Fragment:3個，Controller：3個，Model:2個 | 8個 |
| MVP | Fragment:3個，Presenter:3個，Model:3個，Contract:1個 | 10個 |
| Clean | Fragment:3個，ViewModel:3個，Usecase:18個，Model:3個 | 27個 |
| AAC | Fragment:3個，ViewModel:3個，Model:3個 | 9個 |
View、Controller、Model 相互依賴，造成代碼耦合。
難以分工，難以將 View、Controller、Model 分給不同的人寫。
難以維護，沒有中間件接口做緩沖，難以替換底層的實現(xiàn)。
public class NoteListFragment extends BaseFragment {
...
public void refreshList() {
new Thread(new Runnable() {
@Override
public void run() {
//view 中直接依賴 model。那么 view 須等 model 編寫好才能開工。
mNoteList = mDataManager.getNoteList();
mHandler.sendMessage(REFRESH_LIST, mNoteList);
}
}).start();
}
private Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
switch (msg) {
case REFRESH_LIST:
mAdapter.setList(mNoteList);
mAdapter.notifyDataSetChanged();
break;
default:
}
}
};
...
}
MVP 架構(gòu)的特點與局限
MVP 架構(gòu)的特點是 面向接口編程。在 View、Presenter、Model 之間分別用 中間件接口 做銜接，當(dāng)有新的底層實現(xiàn)時，能夠無縫替換。
此外，MVP 的 View 和 Model 并不產(chǎn)生依賴，因此可以說是對 View 和 Model 做了代碼解耦。
public class NoteListContract {
interface INoteListView {
void showDialog(String msg);
void showTip(String tip);
void refreshList(List beans);
}
interface INoteListPresenter {
void requestNotes(String type);
void updateNotes(NoteBean... beans);
void deleteNotes(NoteBean... beans);
}
interface INoteListModel {
List getNoteList();
int updateNote(NoteBean bean);
int deleteNote(NoteBean bean);
}
}
但 MVP 架構(gòu)有其局限性。按我的理解，MVP 設(shè)計的初衷是， “讓天下沒有難替換的 View 和 Model” 。該初衷背后所基于的假設(shè)是，“上層邏輯穩(wěn)定，但底層實現(xiàn)更替頻繁” 。在這個假設(shè)的引導(dǎo)下，使得三者中， 只有 Presenter 具備獨立意志和決定權(quán)，掌管著 UI 邏輯和業(yè)務(wù)邏輯，而 View 和 Model 只是外接的工具。
public class NoteListPresenter implements NoteListContract.INoteListPresenter {
private NoteListContract.INoteListModel mDataManager;
private NoteListContract.INoteListView mView;
@Override
public void requestNotes(String type) {
Observable.create(new ObservableOnSubscribe>() {
@Override
public void subscribe(ObservableEmitter> e) throws Exception {
List noteBeans = mDataManager.getNoteList();
e.onNext(noteBeans);
}
}).subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread())
.subscribe(new Consumer>() {
@Override
public void accept(List beans) throws Exception {
//presenter 直接干預(yù)了 UI 在拿到數(shù)據(jù)后做什么，使得邏輯上沒有發(fā)生解耦。
//正常來說，解耦意味著，presenter 的職能邊界僅限返回結(jié)果數(shù)據(jù)，
//由 UI 來依據(jù)響應(yīng)碼處理 UI 邏輯。
mView.refreshList(beans);
}
});
}
...
}
然而，這樣的假設(shè)多數(shù)時候并不實際。可視化需求是變化多端的，在牽涉到視覺交互時，必然涉及 UI 邏輯的修改，也就是說，View 和 Presenter 的相互牽連，使得 UI 的改動需要 View 和 Presenter 編寫者配合著完成，增加溝通協(xié)作成本。
長久來看，二者都難以成長。Presenter 編寫者容易被各種非本職工作拖累，View 的編寫者不會嘗試獨立自主，例如通過多態(tài)等模式將 UI 封裝成可適應(yīng)性的組件，反正 ... 有 Presenter 來各種 if else 嘛。
Clean 架構(gòu)的特點和不足為解決 Presenter 職能邊界不明確 的問題，在 Clean 架構(gòu)中，業(yè)務(wù)邏輯的職能被轉(zhuǎn)移到領(lǐng)域?qū)樱?Usecase 專職管理。Presenter 則弱化為 ViewModel ，作為代理數(shù)據(jù)請求，和銜接數(shù)據(jù)回調(diào)的緩沖區(qū)。
Clean 架構(gòu)的特點是 單向依賴、數(shù)據(jù)驅(qū)動編程。 View -> ViewModel -> Usecase -> Model 。
View 對 ViewModel 的單向依賴，是通過 databinding 特性實現(xiàn)的。ViewModel 只負責(zé)代理數(shù)據(jù)請求，在 Usecase 處理完業(yè)務(wù)返回結(jié)果數(shù)據(jù)時，結(jié)果數(shù)據(jù)被賦值給可觀察的 databinding 數(shù)據(jù)，而 View 則依據(jù)數(shù)據(jù)的變化而變化。
public class NoteListViewModel {
private ObservableList mListObservable = new ObservableArrayList<>();
private void requestNotes(String type) {
if (null == mRequestNotesUsecase) {
mRequestNotesUsecase = new ProveListInitUseCase();
}
mUseCaseHandler.execute(mRequestNotesUsecase, new RequestNotesUsecase.RequestValues(type),
new UseCase.UseCaseCallback() {
@Override
public void onSuccess(RequestNotesUsecase.ResponseValue response) {
//viewModel 的可觀察數(shù)據(jù)發(fā)生變化后，databinding 會自動更新 UI 展示。
mListObservable.clear();
mListObservable.addAll(response.getNotes());
}
@Override
public void onError() {
}
});
}
...
}
但 Clean 架構(gòu)也有不足：粒度太細 。一個 Usecase 受限于請求參數(shù)，因而只能處理一類請求。View 請求的數(shù)據(jù)包含幾種類型，就至少需要準(zhǔn)備幾個 Usecase。Usecase 是依據(jù)當(dāng)前 View 對數(shù)據(jù)的需求量身定制的，因此 Usecase 的復(fù)用率極低，項目會因而急劇的增加類和重復(fù)代碼。
