设计模式理解-MVC && MVP && MVVM

MVC

• Model && View && Controller
• MVC也有很多版本，都是根据实际情况来确定的，MVC稍微一变动便成了MVP，MVC是三者里面约束最宽松的，M、V、C三者之前可根据自己的实际需求定义耦合关系
• 最大的特点在于Model可以直接更新View，即对Model和View之间的联系不做要求，可以有联系，也可以无联系
• View和Controller之间是直接联系的，即并不规定Controller和View之间应该通过Interface来交互

MVP

• Model && View && Presenter
• MVP是MVC的扩展版，MVP是MVC的子集，它规定Model和View之间一切的联系都要通过Presenter进行，而且Presenter和View、Model之间互相持有他们的接口
• Model对应Android中的网络请求、数据库处理等，Model往往可以进行Unit Test；
• Presenter是业务逻辑类，是一个Mediator
• View就是对应的Activity

MVVM

• Model && View && ViewModel
• MVVM也相当于MVC的子集，它和MVP一样要求View和Model之间不可以有耦合，一切对View／Model的操作必须由中间件完成，但是MVVM最大的特点就是ViewModel和View之间不是通过接口互相控制的，而是通过数据进行控制／绑定，具体是指
  • MVP从很大程度上解耦了Model和View，最大程度上复用了Model和View，但是承载了具体业务逻辑的Presenter是很难复用的，这是因为它写死的接口
  • ViewModel的角色可以理解为观察者模式中的Observable，VM对V的更新操作可以是一个简单的notify，而如果想使用一个VM对V进行控制，只需要对VM进行一个register，所以从本质上来说，任何一个类型的View都可以绑定任意一个VM，而不必像MVP那样只能和特定接口类型的View绑定
  • 这样ViewModel每次notify View时，View自己对notify传过来的数据进行相应的更新试图操作，举个栗子：
    • View中有一个button，button的颜色是一个RGB(ARGB)值，然后notify传递过来的数据包(也许是一个Map／Dictionary)里取出对应的值，然后View自己刷新自己的页面
• 这样让中间件(ViewModel)更加灵活，耦合也变成了数据上的耦合(这应该属于标记耦合吧，通过接口耦合应该是属于内容耦合)

Conclusion

• 不管MVC、MVP、MVVM其实都是为了最大程度上的解耦、复用，实际应用中也往往会根据自己的需要去变动，理解Pattern的思想才是最重要的