Android 中MVC、MVP以及MVVM架构介绍
MVC、MVP和MVVM是目前Android架构中常见的三种架构设计模式,接下来详细介绍下这三种架构的特点以及差异。
一、MVC
1.定义:
MVC (Model-View-Controller, 模型-视图-控制器),标准的MVC是这个样子的:
- 模型层 (Model):业务逻辑的处理,数据的实体类和存取等;
- 视图层 (View):一般使用XML或者Java对界面进行描述;
- 控制层 (Controller):在Android中通常指Activity和Fragment,或者由其控制的业务类。
在Android中,可以说默认就使用了MVC来进行开发,Model好比我们的方法类,一些具体功能的实现类;而View就类似于我们对应的布局,例如那些xml文件;而Controller就是Activity或者Fragment,它持有View,即控件们的对象,及一些Model,即方法类的对象,并且让他们进行交互,相当于是他们之间的桥梁。
2.交互图:
3.特点:
优点:Model,View,Controller各司其职,区分明确且易于理解。
缺点:由于xml能实现的功能有限,很多View层应该做的事情被迫让Activity,也就是Controller层来做,并且很多业务逻辑也是融合在Activity里,这就导致Controller层逻辑复杂了起来,导致他们之间的分工不再那么明确,最终导致了Activity类过于臃肿,并且View可以直接和Model交互,这让原本应该是Controler层负责的工作又模糊了起来。
4.使用场景:
适用于较小,功能较少,业务逻辑较少的项目。
二、MVP
1.定义:
MVP (Model-View-Presenter) 是MVC的演化版本,几个主要部分如下:
- 模型层 (Model):主要提供数据存取功能。
- 视图层 (View):处理用户事件和视图。在Android中,可能是指Activity、Fragment或者View。
- 协调层 (Presenter):负责通过Model存取数据,连接View和Model,从Model中取出数据交给View。
2.交互图:
3.特点
优点:
(1)模型与视图完全分离,可以修改视图而不影响模型。
(2)可以更高效地使用模型,因为所有的交互都发生在 一个地方——Presenter内部。
(3)可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑。这个特性非常的有用,因为视图的变化总是比模型的变化频繁。
(4)如果把逻辑放在Presenter中,那么就可以脱离用 户接口来测试这些逻辑(单元测试)。
缺点:
由于对视图的渲染放在了Presenter中,所以视图和Presenter的交互会过于频繁。还有一点需要明白,如果Presenter过多地渲染了视图,往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更,那么Presenter也需要变更了。比如说,原本用来呈现Html的Presenter现在也需要用于呈现Pdf了,那么视图很有可能也需要变更。由于View到Model和Model到View都需要Presenter来实现,这使得Presenter也过于笨重,且由于Presenter双向都需要接口来隔离和调用,大量的接口也使得维护的复杂度上升。
4.使用场景:
视图界面不是很多的项目中。
三、MVVM
1.定义:
MVVM 是 Model-View-ViewModel 的简写。它本质上就是 MVC 的改进版。MVVM 就是将其中的 View 的状态和行为抽象化,让我们将视图 UI 和业务逻辑分开。
- 模型层 (Model):负责从各种数据源中获取数据;
- 视图层 (View):在 Android 中对应于 Activity 和 Fragment,用于展示给用户和处理用户交互,会驱动 ViewModel 从 Model 中获取数据;
- ViewModel 层:用于将 Model 和 View 进行关联,我们可以在 View 中通过 ViewModel 从 Model 中获取数据;当获取到了数据之后,会通过自动绑定,比如 DataBinding,来将结果自动刷新到界面上。
2.交互图:
3.特点:
优点:跟MVP中的P相比,VM显得轻量化一些,由于有databind的存在,不需要去自己同步View和Model,所以MVVM相比MVP的类的数量也会少一些。
缺点:由于元素定义在xml中,View关于绑定的这部分内容是没办法打断点进行测试的,且对于小的界面,代码量过于庞大,对于复杂的界面,ViewModel又有些难以构建和维护。
4.使用场景:
适用于界面展示的数据较多的项目。
任何的项目框架,都是为项目服务的。没有绝对的好坏之分,只有更合适的选择。在项目进展的不同阶段,做出最合适的调整,才是是更适合团队项目发展的框架。
任何的项目设计,都是要围绕项目发展阶段,团队成员规模,和团队整体能力而定的。切莫为了设计而设计,为了框架而框架。快速,高效的配合整个团队进展项目,才是最合适的架构。