摘要：架构的特点与局限架构的特点是面向接口编程。架构的特点和不足为解决职能边界不明确的问题，在架构中，业务逻辑的职能被转移到领域层，由专职管理。的作用是视觉交互，为此的职责范围是请求数据和处理逻辑。
声明转载于作者：KunMinX
原文链接：https://www.jianshu.com/p/9ef...
前不久刚结束对 20 模块项目的第 3 轮重构，一路见证 MVC、MVP、Clean 的优缺点并形成自己的体会。
近期在总结工作经验的同时，开始写博客。顺便开源了我设计的 ViaBus 架构。
项目地址：项目常用架构比对
https://github.com/KunMinX/an...
以下，对常见的 MVC、MVP、Clean、AAC 架构做个比对。
首先，一张表格展示各架构的类冗余情况：
需求是，写三个页面，ListFragment、DetailFragment、PreviewFragment，每个页面至少用到 3个 Note 业务、3个 User 业务。问：上述架构分别需编写多少类？
| 架构 | 涉及类 | 类总数 |
|---|---|---|
| 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 分给不同的人写。
难以维护，没有中间件接口做缓冲，难以替换底层的实现。
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 架构的特点与局限
MVP 架构的特点是 面向接口编程。在 View、Presenter、Model 之间分别用 中间件接口 做衔接，当有新的底层实现时，能够无缝替换。
此外，MVP 的 View 和 Model 并不产生依赖，因此可以说是对 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 架构有其局限性。按我的理解，MVP 设计的初衷是， “让天下没有难替换的 View 和 Model” 。该初衷背后所基于的假设是，“上层逻辑稳定，但底层实现更替频繁” 。在这个假设的引导下，使得三者中， 只有 Presenter 具备独立意志和决定权，掌管着 UI 逻辑和业务逻辑，而 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 直接干预了 UI 在拿到数据后做什么，使得逻辑上没有发生解耦。
//正常来说，解耦意味着，presenter 的职能边界仅限返回结果数据，
//由 UI 来依据响应码处理 UI 逻辑。
mView.refreshList(beans);
}
});
}
...
}
然而，这样的假设多数时候并不实际。可视化需求是变化多端的，在牵涉到视觉交互时，必然涉及 UI 逻辑的修改，也就是说，View 和 Presenter 的相互牵连，使得 UI 的改动需要 View 和 Presenter 编写者配合着完成，增加沟通协作成本。
长久来看，二者都难以成长。Presenter 编写者容易被各种非本职工作拖累，View 的编写者不会尝试独立自主，例如通过多态等模式将 UI 封装成可适应性的组件，反正 ... 有 Presenter 来各种 if else 嘛。
Clean 架构的特点和不足为解决 Presenter 职能边界不明确 的问题，在 Clean 架构中，业务逻辑的职能被转移到领域层，由 Usecase 专职管理。Presenter 则弱化为 ViewModel ，作为代理数据请求，和衔接数据回调的缓冲区。
Clean 架构的特点是 单向依赖、数据驱动编程。 View -> ViewModel -> Usecase -> Model 。
View 对 ViewModel 的单向依赖，是通过 databinding 特性实现的。ViewModel 只负责代理数据请求，在 Usecase 处理完业务返回结果数据时，结果数据被赋值给可观察的 databinding 数据，而 View 则依据数据的变化而变化。
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 的可观察数据发生变化后，databinding 会自动更新 UI 展示。
mListObservable.clear();
mListObservable.addAll(response.getNotes());
}
@Override
public void onError() {
}
});
}
...
}
但 Clean 架构也有不足：粒度太细 。一个 Usecase 受限于请求参数，因而只能处理一类请求。View 请求的数据包含几种类型，就至少需要准备几个 Usecase。Usecase 是依据当前 View 对数据的需求量身定制的，因此 Usecase 的复用率极低，项目会因而急剧的增加类和重复代码。
