MVC-MVP-MVVM最小知识

Android MVC代码结构：

MVC定义：实现UI部分的显示和业务逻辑的解耦；

M：业务逻辑处理；
V：处理数据显示部分
C：Activity，Fragment处理用户交互问题；

优点：1.业务逻辑被放置在model层，能够更好的复用和修改增加业务；
2 model层彻底解耦；

缺点：1 controller和view并没有解耦；
2 controller处理复杂逻辑时，承载内容太多，不符合最小单位功能原则；

特点：耦合性低，可扩展性好，模块职责划分明确；

注意事项：层与层之间的交互尽量使用回调或者去使用消息机制去完成，尽量避免直接持有 ；

MVP定义：

M：业务逻辑和实体模型；
V：对应Activity，Fragment，负责view的绘制以及用户的交互；
P：负责完成View和Model间交互；

优点：1 通过中间层Preseter实现了Model和View的完全解耦；
2 引入接口BaseView，让相应的视图组件去实现BaseView，实现了视图层的独立；

缺点：随着业务逻辑的增加，一个页面可能会非常复杂，UI的改变是非常多，会有非常多的case，这样就会造成View的接口会很庞大；

关键点：如何高效设计view对应的接口；

注意事项：
契约类：契约类用于定义同一个界面的view的接口和presenter的具体实现。
优点：通过规范的方法命名和注释可以清晰的看到整个页面的逻辑。

MVVM定义：

V：负责View的绘制和用户交互；
M：实体模型；
VM：负责完成View和Model间的交互，负责业务逻辑；

优点：
实现视图和数据双向绑定；

缺点：
由于数据和视图的双向绑定，导致出现问题时不太好定位来源，有可能数据问题导致，也有可能业务逻辑中对视图属性的修改导致。

注意事项：
在google推出DataBinding之前，因为xml layout功能较弱，想实现MVVM非常困难。

model：包含数据，数据变化，存储等；例如：bean，Retrofit当中的service网络数据的接口，本地数据产生的接口；

MVP和MVVM区别：在MVP中View和presenter要相互持有，方便调用对方，而在MVP中 View和ViewModel通过Binding进行关联，他们之前的关联处理通过DataBinding完成。

选择：
1 项目简单，没什么复杂性，未来改动也不大的话，那就不要用设计模式或者架构方法，只需要将每个模块封装好，方便调用即可，不要为了使用设计模式或架构方法而使用。
2 偏向展示型的app，绝大多数业务逻辑都在后端，app主要功能就是展示数据，交互等，建议使用mvvm。
3 工具类或者需要写很多业务逻辑app，使用mvp或者mvvm都可；

学习注意事项：
需要循序渐进的来掌握了解；

对应的英文单词：
Contract
presenter