浅谈Android开发中的MVVM模式及与MVP和MVC的区别

三种架构模式的演化:

这里写图片描述

什么是MVVM?

MVVM是Model-View-ViewModel的简写。微软的WPF带来了新的技术体验,如Silverlight、音频、视频、3D、动画……,这导致了软件UI层更加细节化、可定制化。同时,在技术层面,WPF也带来了 诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM(Model-View-ViewModel)框架的由来便是MVP(Model-View-Presenter)模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性糅合进去,以应对客户日益复杂的需求变化。

MVC和MVP的关系

MVP是从经典的模式MVC演变而来,它们的基本思想有相通的地方:Controller/Presenter负责逻辑的处理,Model提供数 据,View负责显示。作为一种新的模式,MVP与MVC有着一个重大的区别:在MVP中View并不直接使用Model,它们之间的通信是通过 Presenter (MVC中的Controller)来进行的,所有的交互都发生在Presenter内部,而在MVC中View会直接从Model中读取数据而不是通过 Controller。

MVVM和MVP的关系

而 MVVM 模式将 Presenter 改名为 ViewModel,基本上与 MVP 模式完全一致。 唯一的区别是,它采用双向绑定(data-binding):View的变动,自动反映在 ViewModel,反之亦然。这样开发者就不用处理接收事件和View更新的工作。

具体分析

MVC架构:

View:对应于布局文件
Model:业务逻辑和实体模型
Controllor:对应于Activity

这里写图片描述

View是可以直接访问Model,View里会包含Model信息,不可避免的还要包括一些业务逻辑。Controller是基于行为的,并且可以被多个View共享。在MVC模型里,更关注的Model的不变,而同时有多个对Model的不同显示,及View。Model不依赖于View,但是 View是依赖于Model。

MVP架构:

View: 对应于Activity,负责View的绘制以及与用户交互
Model: 依然是业务逻辑和实体模型
Presenter: 负责完成View于Model间的交互

这里写图片描述

View不直接与Model交互,而是通过与Presenter交互来与Model间接交互。Presenter与View的交互是通过接口来进行的。通常View与Presenter是一对一的,但复杂的View可能绑定多个Presenter来处理逻辑

MVP的优点

1、Model与View完全分离,修改互不影响
2、更高效地使用,因为所有的逻辑交互都发生在一个地方—Presenter内部
3、一个Preseter可用于多个View,而不需要改变Presenter的逻辑(因为View的变化总是比Model的变化频繁)。
4、更便于测试。把逻辑放在Presenter中,就可以脱离用户接口来测试逻辑(单元测试)

MVVM架构:

Model:代表你的基本业务逻辑
View:显示内容
ViewModel:将前面两者联系在一起的对象

这里写图片描述

一个ViewModel接口提供了两个东西:动作和数据。动作改变Model的下层(click listener,监听文字改变的listener等等),而数据则是Model的内容。

在MVVM中,View/Model的变动,自动反映在 ViewModel,反之亦然。这两个组件只是通过ViewModel松耦合在一起。这种设计模式之所以好用和方便,除了明显智能化了的View之外,还方便了测试。因为ViewModel不在依赖于View了,你可以在没有View的情况下也能测试ViewModel。在合适的依赖注入的帮助下,测试就会变得非常简单。

MVVM的优点

  1. 低耦合。视图(View)可以独立于Model变化和修改,一个ViewModel可以绑定到不同的”View”上,当View变化的时候Model可以不变,当Model变化的时候View也可以不变。

  2. 可重用性。你可以把一些视图逻辑放在一个ViewModel里面,让很多view重用这段视图逻辑。

  3. 独立开发。开发人员可以专注于业务逻辑和数据的开发(ViewModel),设计人员可以专注于页面设计。

  4. 可测试。界面素来是比较难于测试的,而现在测试可以针对ViewModel来写

总结:

任何的项目框架,都是为项目服务的。没有绝对的好坏之分,只有更合适的选择。在项目进展的不同阶段,做出最合适的调整,才是是更适合团队项目发展的框架。项目设计者要谨记,任何的项目设计,都是要围绕项目发展阶段,团队成员规模,和团队整体能力而定的。切莫为了设计而设计,为了框架而框架。快速,高效的配合整个团队进展项目,才是最合适的架构。才是一个程序员为成一个leader,成为一个架构师的必经之路。

猜你喜欢

转载自blog.csdn.net/SilenceOO/article/details/77849543