小议MVC、MVP、MVVP架构模式

目录

用 [TOC]来生成目录：

---

　　架构模式从来都是为了解决问题而生的，Android里的MVC Model和View耦合，出现了MVP，又因为activity与实际界面与presenter耦合出现了想将view与activity降低耦合的MVVP，或者其他架构模式。
　　

MVC

• 观察者模式最初始的模块归类模型
  　　MVC模式作为古老的开发架构，老少皆知。三年Android开发的我表示，还是它用着舒心。
  　　作为观察者模式的直接体现，Controller观察到Model变化通知View进行响应。结构层级清晰（可以从业务流向或者面向对象角度解释），关系如下图所示：

Created with Raphaël 2.1.2 Model Model Controller Controller View View observed data changed 数据变化了(with Obj) notify page to flush 界面刷新(with Adapter Or data)

• 比java版本的MVC多了Model和View的耦合
  　　Model和View模块的耦合，不可避免，毕竟Android比JAVA后端更接近底层一些。但其实使用第三方或者自己写接口、抽象类、Message/注解，也可以做到降低耦合或者看起来降低了耦合。ButterKnife中注解插入代码的做法其实就是看起来降低了耦合，不管用反射还是apt&javaPoet。
• 仍可以做到代码量少、阅读性好
  　　我喜欢MVC的一点就是简单粗暴也灵活。接口可能会降低下层实现类之间的耦合，但其实增加了接口的维护，也下转上也限制了类的表现【我只需要做一件小事，可能这件事只包含于众多表现业务，我仍然要在接口声明业务】
  　　

MVP

• 官方demo接口声明过于直接，我更倾向于使用clean版本
  　　MVP模式相信很多人都已经清楚了，它才是真正的MVC。它是为了解决MVC中Model和View模块存在耦合的问题产生的。
  　　我倾向于clean，原因有以下几点：
  　　1. 接口声明更简单，导致下层更加简单。只给处于架构最底层的View声明BaseView即可。既然MVP模式中activity或者fragment就是对应View，那么Presenter与activity/fragment一一对应在所难免。还不如摒弃官方Contact，况且官方写法也只是为了说明P与V之间一一对应的关系吧。
  　　2. 既然P与V一一对应，也就是与activity/fragment一一对应，那么Presenter不如直接以对象声明的形式出现在组件中岂不是更加自然一些。反倒出现一些类似于以下情节：
  　　

MvpActivity extends AppCompatActivity implements BaseView{
  ...
  BasePresenter mBasePresenter = new MPresenter((BaseView) this);

  mBasePresenter.attachView((BaseView) this);
  ...
}

　　看似在降低耦合，但其实MVP架构并不需要为Presenter与View降低耦合。况且不管你用接口，抽象类，Message吗，也都只能降低耦合，并不可能做到解耦！ 试问：如果接口或抽象层都耦合了，虽然代码层面降低了下层实现类的耦合，但下层类在业务上必定耦合。接口/抽象层对应业务，实现类对应表现。

• 接口声明导致下层代码关系复杂，阅读难度增加

• 仍存在View与activity组件及presenter的耦合，影响视觉体验

MVVP

---

未完，待续