涨薪机密——新潮流新技术、新框架，

初探安卓MVVM框架设计

一. 什么是MVVM?MVVM是近几年流行的一种设计框架,基于该框架设计的应用程序具有良好的解耦和可扩展性,大幅降低了维护成本,提高了程序员的开发效率.在了解MVVM框架之前,我们有必要回顾一下其他设计框架.

1. MVC模式MVC模式的意思是,软件可以分成三个部分.
视图（View）：用户界面
控制器（Controller）：业务逻辑
模型（Model）：数据保存
各部分之间的通信方式如下.



1.View传送指令到Controller
2.Controller完成业务逻辑后,要求Model改变状态
3.Model将新的数据发送到View,用户得到反馈
所有通信都是单向的.我们传统的Android开发都是基于这种模式.每一层可以代表我们常用的如下组件:
Model层: sqlite数据库, JavaBean, SharedPreference, sdcard,获取网络数据的api等
View层: xml布局文件,自定义控件等
Controller层: Activity等
此处需要注意的是,在传统的MVC设计模式中,
Activity属于Controller层而不是View层,因为Activity即承担了数据调用,也承担了界面展示,相当于View和Model中间的协调器.很多初学者都会误认为Activity属于View层.当然,这种说法仅限用MVC模式,换做其他模式就不一定了!

2.  MVP模式MVC模式普及了一段时间之后,逐渐暴露出一些问题.比如我们发现,
Activity中写的代码太多,有时候一个Activity甚至达到了四五千行代码,维护起来极为不便.原因也很明显,就是Activity既参与api访问和数据调用,又参与了界面的更新,职能划分不明确,没有完全实现解耦.我们的想法是,能不能让Activity只做界面响应和更新,其他业务逻辑全部由另外一个单独模块来完成?于是MVP诞生了.
MVP模式将Controller改名为Presenter,同时改变了通信方向.


1.各部分之间的通信,都是双向的.
2.View与Model不发生联系,都通过Presenter传递.
3.View非常薄,不部署任何业务逻辑,称为"被动视图"（Passive View）,即没有任何主动性,而Presenter非常厚,所有逻辑都部署在那里.
当这样调整了之后, Activity就纯粹属于View层了,所有业务逻辑全由Presenter来完成.当View界面被用户操作时(比如按钮点击), View层就会调用Presenter完成相关业务逻辑,而Presenter完成了之后,就会将结果以回调的形式传递给View层,由View层完成界面刷新.具体代码如何实现我就不多说了,因为我们今天的重点是MVVM

3. MVVM模式当我们采用MVP模式之后,发现Activity几乎没啥事可做了,我们的项目代码层级也清晰了,也好维护了.但是MVP也有缺点,比如,为了实现MVP,我们需要额外增加好多接口和类,比如,一个Activity需要对应一个Presenter类和Presenter接口,同时为了方便Activity和Presenter进行通信,还得再定义一个回调接口IView,也就是说,每一个Activity都需要额外增加两个接口和一个类,无疑提高了代码量.而MVVM的诞生,就解决了这个问题!
MVVM模式将Presenter改名为ViewModel,基本上与MVP模式完全一致.



唯一的区别是,它采用双向绑定（data-binding）：View的变动,自动反映在ViewModel,反之亦然.
有没有注意到, MVVM和MVP几乎是一样的,唯一的不同就在于View和ViewModel之间的那根线, MVP是两根,表示View调用Presenter执行逻辑,Presenter调用View来返回数据,更新界面;MVVM中只有一根线两个箭头,代表的是View和ViewModel双向绑定,自动同步数据,无需手动调用相关方法进行通信,从而减少了代码量.而这种双向绑定的机制,都归功于谷歌推出的DataBinding的新功能.下面我们来研究一下到底什么是DataBinding.

涨薪机密——新潮流新技术、新框架，

初探安卓MVVM框架设计

一. 什么是MVVM?MVVM是近几年流行的一种设计框架,基于该框架设计的应用程序具有良好的解耦和可扩展性,大幅降低了维护成本,提高了程序员的开发效率.在了解MVVM框架之前,我们有必要回顾一下其他设计框架.

1. MVC模式MVC模式的意思是,软件可以分成三个部分.
视图（View）：用户界面
控制器（Controller）：业务逻辑
模型（Model）：数据保存
各部分之间的通信方式如下.



1.View传送指令到Controller
2.Controller完成业务逻辑后,要求Model改变状态
3.Model将新的数据发送到View,用户得到反馈
所有通信都是单向的.我们传统的Android开发都是基于这种模式.每一层可以代表我们常用的如下组件:
Model层: sqlite数据库, JavaBean, SharedPreference, sdcard,获取网络数据的api等
View层: xml布局文件,自定义控件等
Controller层: Activity等
此处需要注意的是,在传统的MVC设计模式中,
Activity属于Controller层而不是View层,因为Activity即承担了数据调用,也承担了界面展示,相当于View和Model中间的协调器.很多初学者都会误认为Activity属于View层.当然,这种说法仅限用MVC模式,换做其他模式就不一定了!

2.  MVP模式MVC模式普及了一段时间之后,逐渐暴露出一些问题.比如我们发现,
Activity中写的代码太多,有时候一个Activity甚至达到了四五千行代码,维护起来极为不便.原因也很明显,就是Activity既参与api访问和数据调用,又参与了界面的更新,职能划分不明确,没有完全实现解耦.我们的想法是,能不能让Activity只做界面响应和更新,其他业务逻辑全部由另外一个单独模块来完成?于是MVP诞生了.
MVP模式将Controller改名为Presenter,同时改变了通信方向.


1.各部分之间的通信,都是双向的.
2.View与Model不发生联系,都通过Presenter传递.
3.View非常薄,不部署任何业务逻辑,称为"被动视图"（Passive View）,即没有任何主动性,而Presenter非常厚,所有逻辑都部署在那里.
当这样调整了之后, Activity就纯粹属于View层了,所有业务逻辑全由Presenter来完成.当View界面被用户操作时(比如按钮点击), View层就会调用Presenter完成相关业务逻辑,而Presenter完成了之后,就会将结果以回调的形式传递给View层,由View层完成界面刷新.具体代码如何实现我就不多说了,因为我们今天的重点是MVVM

3. MVVM模式当我们采用MVP模式之后,发现Activity几乎没啥事可做了,我们的项目代码层级也清晰了,也好维护了.但是MVP也有缺点,比如,为了实现MVP,我们需要额外增加好多接口和类,比如,一个Activity需要对应一个Presenter类和Presenter接口,同时为了方便Activity和Presenter进行通信,还得再定义一个回调接口IView,也就是说,每一个Activity都需要额外增加两个接口和一个类,无疑提高了代码量.而MVVM的诞生,就解决了这个问题!
MVVM模式将Presenter改名为ViewModel,基本上与MVP模式完全一致.



唯一的区别是,它采用双向绑定（data-binding）：View的变动,自动反映在ViewModel,反之亦然.
有没有注意到, MVVM和MVP几乎是一样的,唯一的不同就在于View和ViewModel之间的那根线, MVP是两根,表示View调用Presenter执行逻辑,Presenter调用View来返回数据,更新界面;MVVM中只有一根线两个箭头,代表的是View和ViewModel双向绑定,自动同步数据,无需手动调用相关方法进行通信,从而减少了代码量.而这种双向绑定的机制,都归功于谷歌推出的DataBinding的新功能.下面我们来研究一下到底什么是DataBinding.