不看不知道设计模式2

目前市面上使用的模式主流的有：MVC,MVP,MVVM三种。

 

MVC

mvc模式是模型，视图，控制器三种不同功能的组合，你中有我我中有你。

 

 

如图，实线代表方法调用，虚线代表事件通知。

MVC允许在不改变视图的情况下改变视图对用户输入的响应方式，用户对View的操作交给了Controller处理，在Controller中响应View的事件调用Model的接口对数据进行操作，一旦Model发生变化便通知相关视图进行更新。

View层：代表的是xml布局、自定义控件等显示类层级

Controllr层；代表的是activity、fragment等，主要处理接收点击事件，生成Model层对象等工作

Model层：代表数据操作数据对象等

如简单的网易新闻客户端，设计为MVC模式时，界面的xml布局属于V层，activty、fragment数据Controller层，接收网络数据及处理是Model层；当用户点击，事件input到controller处理，然后控制View刷新；或者当用户滑动加载跟多数据时，Controller通知Model层，Model层进行网络请求，加载更多的数据，然后通过Model层操作View层进行数据刷新，更新UI

这样的设计比较直观，各层之间有变化都可以用最近的方式通知到对应层并进行更新；但是也存在很多问题：

1、M/V/C层相互依赖，代码耦合性太高

2、难以分工，无法将M/V/C的功能分别给不同的人写

3、关联太强难以维护、难以单元测试

 

MVP

MVP（Model-View-Presenter）是MVC模式的改良。和MVC的相同之处在于：Controller/Presenter负责业务逻辑，Model管理数据，View负责显示。

 

 

 

虽然在MVC里，View是可以直接访问Model的，但MVP中的View并不能直接使用Model，而是通过为Presenter提供接口，让Presenter去更新Model，再通过观察者模式更新View。

与MVC相比，MVP模式通过解耦View和Model，完全分离视图和模型使职责划分更加清晰；由于View不依赖Model，可以将View抽离出来做成组件，它只需要提供一系列接口提供给上层操作。

View层：代表的是xml布局、activity、fragment等

Presenter层；ActivityPresenter、FragmentPresenter等作为View层与Model层之间交互的纽带

Model层：代表数据操作数据对象等

以美团外卖为例：Model中的数据对象bean包、网络处理net包、数据库的dao包，作用为数据的存储和加载；通过FragmentPresenter为纽带将加载的数据刷新到View层的activity和fragment；用户的点击滑动等点单退单事件，通过Presenter为纽带交给Model层将数据保存到本地数据库及上传服务器。

优点：

1、View层和Model层都独立出来，实现完全解耦，可以分别进行扩展，相互的影响性小，便于维护和测试

2、部分activity、fragment的逻辑放在P层处理，减少了activity和fragment的臃肿

缺点：

1、所有的处理几乎都要经过P层，部分P层还要处理activity的逻辑，可能带来P层臃肿

 

MVVM

MVVM（Model-View-ViewModel）最早由微软提出。ViewModel指 "Model of View"——视图的模型。这个概念曾在一段时间内被前端圈热炒，以至于很多初学者拿jQuery和Vue做对比...

 

 

MVVM把View和Model的同步逻辑自动化了。以前Presenter负责的View和Model同步不再手动地进行操作，而是交给框架所提供的数据绑定功能进行负责，只需要告诉它View显示的数据对应的是Model哪一部分即可。

核心就是把原来P层手动处理的操作交给框架处理，由框架DataBinding 自动完成数据绑定。实现过程参照：https://www.jianshu.com/p/f9d6677a88f4， 

优点：

简单快捷，更加实用，app就是要处理界面View和数据Model，现在也只有处理这两个层。

缺点：

1、由于中间层直接由绑定完成了，数据绑定使得 Bug 很难被调试，你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。

2、一个大的模块中，model也会很大，虽然使用方便了也很容易保证了数据的一致性，当时长期持有，不释放内存，就造成了花费更多的内存。