MVC、MVP、MVVM设计模式

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_33706840/article/details/81587464

为什么需要设计模式

  • 使得程序模块化,分工明确
  • 模块内部高内聚低耦合
  • 开发过程中只关注于一点,可以提高开发效率
  • 可扩展性,维护性好

1、MVC设计模式

  • 模型层(Model)

    业务逻辑与实体类模型,主要负责网络请求,数据库处理,I/O流操作等。

  • 视图层(View)

    对应于布局文件。

  • 控制层(Controller)

    Android中的控制层由Activity来承担,主要做一些初始化页面,展示数据,同时还要处理控制逻辑,显得很臃肿。

2、MVP设计模式

  • 视图层(View)

    负责绘制UI元素、与用户进行交互,对应于xml、Activity、Fragment。

  • 模型层(Model)

    负责存储与操纵数据,一般包含网络请求,数据库处理,I/O流。

  • 控制层(Presenter)

    Presenter是作为View与Model交互的中间纽带,处理View于Model间的交互和业务逻辑。

这里写图片描述

MVP优点

  • 接收到View的请求,从Model层获取数据,将数据进行处理,通过View层的接口回调给Activity或者Fragment。MVP能够让Activity只做UI相关的事。

  • 模型与视图完全分离,我们可以修改视图而不影响模型。

  • 我们可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑,这个特性非常的有用,因为视图的变化总是比模型的变化频繁。

MVP缺点

  • Presente层与View层是通过接口进行交互的,View层可能会有大量的接口,因为有可能好几个Activity都是去实现同一个View接口,那么所有用到的Activity都要去实现所有的方法(不管你是否用到),而且如果后面有些方法要删改,Presenter和Activity都要改动,比较麻烦。

  • MVP把Activity相当的一部分责任放到了Presenter来处理,复杂的业务同时也可能会导致P层太大,一旦业务逻辑越来越多,View定义的方法越来越多,会造成Activity和Fragment实现的方法越来越多,依然臃肿。

MVVM设计模式

  • 模型层(Model)

    负责数据实现和逻辑处理。

  • 视图层(View)

    对应于Activity和XML,负责View的绘制以及与用户交互

  • 视图模型层(ViewModel )

    将Model和View绑定起来,Model的更改,通过ViewModel 反馈给View,从而自动刷新界面。

    ViewModel 只做和业务逻辑和业务数据相关的事,不做任何和UI、控件相关的事,ViewModel 层不会持有任何控件的引用,更不会在ViewModel中通过UI控件的引用去做更新UI的事情。ViewModel就是专注于业务的逻辑处理,操作的也都是对数据进行操作,这些个数据源绑定在相应的控件上会自动去更改UI,开发者不需要关心更新UI的事情。

  • 通常情况下,数据的流向是单方面的,只能从代码流向UI,也就是单向绑定;而双向绑定的数据流向是双向的,当业务代码中的数据改变时,UI上的数据能够得到刷新;当用户通过UI交互编辑了数据时,数据的变化也能自动的更新到业务代码中的数据上。而DataBinding是一个实现数据和UI绑定的框架,是构建MVVM模式的一个关键的工具,它是支持双向绑定的。

    View层的Activity通过DataBinding生成Binding实例,把这个实例传递给ViewModel,ViewModel层通过把自身与Binding实例绑定,从而实现View中layout与ViewModel的双向绑定。mvvm的缺点数据绑定使得 Bug 很难被调试。你看到界面异常了,有可能是你 View 的代码有 Bug,也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置,要定位原始出问题的地方就变得不那么容易了。

猜你喜欢

转载自blog.csdn.net/qq_33706840/article/details/81587464