MVVM
MVVM可以算是MVP的升级版； 其中的VM是ViewModel的缩写，ViewModel可以理解成是View的数据模型和Presenter的合体； ViewModel和View之间的交互通过Data Binding完成，而Data Binding可以实现双向的交互，这就使得视图和控制层之间的耦合程度进一步降低，关注点分离更为彻底，同时减轻了Activity的压力
刚开始理解这些概念的时候认为这几种模式虽然都是要将view和model解耦，但是非此即彼，没有关系，一个应用只会用一种模式；后来慢慢发现世界绝对不是只有黑白两面，中间最大的一块其实是灰色地带，同样，这几种模式的边界并非那么明显，可能你在自己的应用中都会用到；实际上也根本没必要去纠结自己到底用的是MVC、MVP还是MVVP，不管黑猫白猫，捉住老鼠就是好猫。
MVC->MVP->MVVM演进过程
MVC -> MVP -> MVVM 这几个软件设计模式是一步步演化发展的； MVVM 是从 MVP 的进一步发展与规范，MVP 隔离了MVC中的 M 与 V 的直接联系后，靠 Presenter 来中转，所以使用 MVP 时 P 是直接调用 View 的接口来实现对视图的操作的，这个 View 接口的东西一般来说是 showData、showLoading等等；M 与 V已经隔离了，方便测试了，但代码还不够优雅简洁
所以 MVVM 就弥补了这些缺陷； 在 MVVM 中就出现的 Data Binding 这个概念，意思就是 View 接口的 showData 这些实现方法可以不写了，通过 Binding 来实现
如果把这三者放在一起比较，先说一下三者的共同点，也就是Model和View：
-
Model：数据对象，同时，提供本应用外部对应用程序数据的操作的接口，也可能在数据变化时发出变更通知。Model不依赖于View的实现，只要外部程序调用Model的接口就能够实现对数据的增删改查
-
View：UI层，提供对最终用户的交互操作功能，包括UI展现代码及一些相关的界面逻辑代码
三者的差异在于如何粘合View和Model，实现用户的交互操作以及变更通知
Controller
- Controller接收View的操作事件，根据事件不同，或者调用Model的接口进行数据操作，或者进行View的跳转，从而也意味着一个Controller可以对应多个View； Controller对View的实现不太关心，只会被动地接收，Model的数据变更不通过Controller直接通知View，通常View采用观察者模式监听Model的变化
Presenter
- Presenter与Controller一样，接收View的命令，对Model进行操作； 与Controller不同的是Presenter会反作用于View，Model的变更通知首先被Presenter获得，然后Presenter再去更新View；一个Presenter只对应于一个View
根据Presenter和View对逻辑代码分担的程度不同，这种模式又有两种情况：Passive View和Supervisor Controller
ViewModel
- 注意这里的 “Model” 指的是 View的Model； 跟MVVM中的一个Model不是一回事，所谓View的Model就是包含View的一些数据属性和操作的这么一个东东，这种模式的关键技术就是数据绑定（data binding），View的变化会直接影响ViewModel，ViewModel的变化或者内容也会直接体现在View上。这种模式实际上是框架替应用开发者做了一些工作，开发者只需要较少的代码就能实现比较复杂的交互
MVP和MVVM完全隔离了Model和View； 但是在有些情况下，数据从Model到ViewModel或者Presenter的拷贝开销很大，可能也会结合MVC的方式，Model直接通知View进行变更
在实际的应用中很有可能你已经在不知不觉中将几种模式融合在一起； 但是为了代码的可扩展、可测试性，必须做到模块的解耦，不相关的代码不要放在一起；网上有一个故事讲，一个人在一家公司做一个新产品时，一名外包公司的新员工直接在View中做了数据库持久化操作，而且一个hibernate代码展开后发现竟然有几百行的SQL语句，搞得他们惊讶不已，一时成为笑谈
个人理解，在广义地谈论MVC架构时，并非指本文中严格定义的MVC，而是指的MV；* 也就是视图和模型的分离，只要一个框架提供了视图和模型分离的功能，我们就可以认为它是一个MVC框架。在开发深入之后，可以再体会用到的框架到底是 MVC、MVP还是MVVM?
基于AOP的框架设计
AOP(Aspect-Oriented Programming, 面向切面编程)； 诞生于上个世纪90年代，是对OOP(Object-Oriented Programming, 面向对象编程)的补充和完善；OOP引入封装、继承和多态性等概念来建立一种对象层次结构，用以模拟公共行为的一个集合
当我们需要为分散的对象引入公共行为的时候，OOP则显得无能为力； 也就是说，OOP允许你定义从上到下的关系，但并不适合定义从左到右的关系。例如日志功能。日志代码往往水平地散布在所有对象层次中，而与它所散布到的对象的核心功能毫无关系
对于其他类型的代码，如安全性、异常处理和透明的持续性也是如此； 这种散布在各处的无关的代码被称为横切（Cross-Cutting）代码，在OOP设计中，它导致了大量代码的重复，而不利于各个模块的重用。而AOP技术则恰恰相反，它利用一种称为“横切”的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其名为“Aspect”，即方面。所谓“方面”，简单地说，就是将那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性
AOP在Android中的使用
AOP把软件系统分为两个部分：核心关注点和横切关注点； 业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处都基本相似
AOP的作用在于分离系统中的各种关注点，将核心关注点和横切关注点分离开来
在Android App中，哪些是我们需要的横切关注点？ 个人认为主要包括以下几个方面：Http, SharedPreferences, Json, Xml, File, Device, System, Log, 格式转换 等；Android App的需求差别很大，不同的需求横切关注点必然是不一样的； 一般的App工程中应该有一个Util Package来存放相关的切面操作，在项目多了之后可以将其中使用较多的Util封装为一个Jar包供工程调用
在使用MVVM和AOP对App进行纵向和横向的切割之后； 能够使得App整体的结构更清晰合理，避免局部的代码臃肿，方便开发、测试以及后续的维护
网友评论