MVC模式原理
MVC，即Model-View-Controller，意味：模型、视图和控制器。
-
Model
- 程序需要操作的数据来源。通常是从数据库、网络请求或者是
Bean数据。 - 负责提供数据
- 程序需要操作的数据来源。通常是从数据库、网络请求或者是
-
View
- 程序用来展示内容的界面。通常是
Activity、Fragment等UI组件。 - 负责展示数据
- 程序用来展示内容的界面。通常是
-
Controller
- 程序中用于处理
Model数据业务逻辑并将结果输送给View的中间层。 - 负责处理业务逻辑
- 程序中用于处理
MVC模式流程.png
实际开发中
Activity究竟算Controller还是View说不清楚。理论上Activity是UI组件负责展示内容，但很多项目中Activity处理了太多的业务逻辑操作。超过1000行代码太常见了。根据这种情况我将Activity放到Controller上。只是个人习惯而已！
优缺点
- 优点
- 耦合性低：视图层和业务层分离。
- 重用性高：多个
View能共享同一个Model。 - 部署快：责任分离，各司其职，职责清晰。
- 可维护性高
- 缺点
-
Controller角色比重太大。虽然担任控制器的职责，但现实开发中类似Activity的UI却做了很多View相关操作。VC分离不清。 - 优点中的耦合性低是相对的，现实中
MVC的耦合性确实不低！
-
MVP模式原理
知道了MVC的不足之处，MVP就是为了解决VC耦合这个问题，在MVC的基础上变种出来的框架。
M几乎没有变化，只是把VC抽出来变成了VP。
MVP核心思想：
MVP把Activity中的UI逻辑抽象成View接口，把业务逻辑抽象成Presenter接口，Model类还是原来的Model。
减轻了Activity的工作，因为大部分工作都丢到了Presenter那去了。自己只要管理好生命周期即可。
MVP模式.png
根据上图，代码所需的实现：
- 创建
IPresenter表示业务逻辑接口，由PresenterImpl实现 - 创建
IView接口表示UI逻辑实现，由Activity、Fragment等UI组件实现 -
Activity关联PresenterImpl用于调用业务方法 -
PresenterImpl关联Activity用于调用UI方法 -
Model木有变化，还是原来的Model~♪(∇*)
优缺点
- 优点
- 结构清晰，比
MVC要清晰多了
- 结构清晰，比
- 缺点
- 每个
View都有个Presenter，多了也是个麻烦~
- 每个
MVVM模式原理
MVVM模式利用了一个工具DataBinding实现了其中的VM。将数据和View绑定在一起，这样一来，数据发生改变，View会即时更新。
-
Model
-
Model还是原来的Model，负责提供实体模型。供VM使用。
-
-
View
-
Activity、Fragment以及View组件，这一块只包含UI相关代码。不含有一点业务逻辑代码。 - 这才是真正的
View模块，View模块就应该只负责UI逻辑。
-
-
ViewModel
- 只负责业务逻辑
- 将
Model提供的实体数据和View中真正展示数据的UI组件通过DataBinding绑定在一起。 - 我们就不用像以前那样，等
Bean改变后，get里面的属性值。然后获取UI组件的引用，将属性值设置到UI组件上。 -
VM绑定在一起，Model一改变，View自动实时更新！
MVVM模式.png
优缺点
- 优点
-
双向绑定技术，
Model变化，View自动更新。或者说，Model变化，ViewModel和View自动更新（角度不一样而已）。 - 模块之间职责更清晰。
- 控制器功能大都到了
View上，大大减轻压力。
-
双向绑定技术，
- 缺点
-
DataBinding后很难进行调试，出现问题很难进行定位。 - 大项目中
Model会很大，长期占有不能释放会占内存。 -
View的重用性降低，MVVM中的一个View绑定一个Model。不同模块的View都不同，重用困难。
-
