MVC、MVP和MVVM的原理与比较

MVC模式原理

MVC，即Model-View-Controller，意味：模型、视图和控制器。

• Model

  • 程序需要操作的数据来源。通常是从数据库、网络请求或者是Bean数据。
  • 负责提供数据

• View

  • 程序用来展示内容的界面。通常是Activity、Fragment等UI组件。
  • 负责展示数据

• Controller

  • 程序中用于处理Model数据业务逻辑并将结果输送给View的中间层。
  • 负责处理业务逻辑

实际开发中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那去了。自己只要管理好生命周期即可。

根据上图，代码所需的实现：

• 创建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自动实时更新！

优缺点

• 优点

  • 双向绑定技术，Model变化，View自动更新。或者说，Model变化，ViewModel和View自动更新（角度不一样而已）。
  • 模块之间职责更清晰。
  • 控制器功能大都到了View上，大大减轻压力。

• 缺点

  • DataBinding后很难进行调试，出现问题很难进行定位。
  • 大项目中Model会很大，长期占有不能释放会占内存。
  • View的重用性降低，MVVM中的一个View绑定一个Model。不同模块的View都不同，重用困难。