前言
当我们接手一个项目的时候，经常会发现一个activity或fragment动辄上千行甚至上万行代码，这给阅读带来很大的困扰，如果想读懂代码，需要花费很多时间跟精力。引起这个问题的原因想必大家都了解，随着人员不断变动，需求不断增多，在没有严格代码规范的前提下，每个人都是根据自己的偏好把需求做完，最后是代码越堆越多，维护性越来越差。为什么大家都喜欢往activity里面堆代码呢？究其原因，是因为android里面xml视图功能太弱，activity不仅要承担视图显示，还要加入控制逻辑，承担太多职责，代码就会越堆越多。
在MVC之前，有些人会考虑把activity的控制逻辑抽成Manager，但是也没有一致的规范标准，只是让代码看着清爽了些，并没有从本质上把问题解决掉，也就是View层跟controller层并未解耦。为了解决这个问题，MVP出现了，虽然可以代替activity处理大部分控制逻辑，但是MVP也存在瑕疵，代码量变大，接口变多等，因为Presenter要持有view的引用，感觉两者并未完全解耦。此时MVVM出现了，好像就是为了完善MVP的不足而设计的，在这种模式下，viewmodle跟view之间的交互是通过Data Binding来完成的，Data Binding可以实现双向的交互，这就使得视图跟控制层之间的耦合度进一步降低。
一. MVC
Model-View-Controller.png
MVC全称Model View Controller,如上图,是模型(model)-视图(view)-控制器(controller)的缩写,用一种业务逻辑、数据、界面显示分离的方法组织代码。
其中M层处理数据,业务逻辑等;V层处理界面的显示结果;C层起到桥梁的作用,来控制V层和M层通信以此来达到分离视图显示和业务逻辑层。
Android中界面部分也采用了当前比较流行的MVC框架,在Android中:
视图层(View)
一般采用XML文件进行界面的描述,这些XML可以理解为AndroidApp的View。使用的时候可以非常方便的引入。同时便于后期界面的修改。逻辑中与界面对应的id不变化则代码不用修改,大大增强了代码的可维护性。
控制层(Controller)
Android的控制层的重任通常落在了众多的Activity的肩上。这句话也就暗含了不要在Activity中写代码,要通过Activity交割Model业务逻辑层处理,这样做的另外一个原因是Android中的Actiivity的响应时间是5s,如果耗时的操作放在这里,程序就很容易被回收掉。
模型层(Model)
我们针对业务模型,建立的数据结构和相关的类,就可以理解为AndroidApp的Model,Model是与View无关,而与业务相关的。对数据库的操作、对网络等的操作都应该在Model里面处理,当然对业务计算等操作也是必须放在的该层的。就是应用程序中二进制的数据。
一. MVP
Model-View-Presenter.png
MVP框架由3部分组成:View负责显示,Presenter负责逻辑处理,Model提供数据。在MVP模式里通常包含3个要素(加上View interface是4个):
View
负责绘制UI元素、与用户进行交互(在Android中体现为Activity)
Model
负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)
Presenter
作为View与Model交互的中间纽带,处理与用户交互的负责逻辑。
因此我们可以发现MVP的优点如下:
1、模型与视图完全分离,我们可以修改视图而不影响模型;
2、可以更高效地使用模型,因为所有的交互都发生在一个地方——Presenter内部;
3、我们可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑。这个特性非常的有用,因为视图的变化总是比模型的变化频繁;
4、如果我们把逻辑放在Presenter中,那么我们就可以脱离用户接口来测试这些逻辑(单元测试)。
一. MVVM
Model-View-ViewModel.png
View
View层做的就是和UI相关的工作，我们只在XML和Activity或Fragment写View层的代码，View层不做和业务相关的事，也就是我们的Activity 不写和业务逻辑相关代码，也不写需要根据业务逻辑来更新UI的代码，因为更新UI通过Binding实现，更新UI在ViewModel里面做(更新绑定的数据源即可)，Activity 要做的事就是初始化一些控件(如控件的颜色，添加 RecyclerView 的分割线)，Activity可以更新UI，但是更新的UI必须和业务逻辑和数据是没有关系的，只是单纯的根据点击或者滑动等事件更新UI(如 根据滑动颜色渐变、根据点击隐藏等单纯UI逻辑)，Activity(View层)是可以处理UI事件，但是处理的只是处理UI自己的事情，View层只处理View层的事。简单的说：View层不做任何业务逻辑、不涉及操作数据、不处理数据、UI和数据严格的分开。
ViewModel
ViewModel层做的事情刚好和View层相反，ViewModel 只做和业务逻辑和业务数据相关的事，不做任何和UI、控件相关的事，ViewModel 层不会持有任何控件的引用，更不会在ViewModel中通过UI控件的引用去做更新UI的事情。ViewModel就是专注于业务的逻辑处理，操作的也都是对数据进行操作，这些个数据源绑定在相应的控件上会自动去更改UI，开发者不需要关心更新UI的事情。关于对UI控件事件的处理，我们也希望能把这些事件处理绑定到控件上，并把这些事件统一化，方便ViewModel对事件的处理和代码的美观。为此我们通过BindingAdapter 对一些常用的事件做了封装，把一个个事件封装成一个个Command，对于每个事件我们用一个ReplyCommand去处理就行了,ReplyCommand会把可能你需要的数据带给你，这使得我们处理事件的时候也只关心处理数据就行了，再强调一遍ViewModel 不做和UI相关的事。
Model
Model 的职责很简单，基本就是实体模型(Bean)同时包括Retrofit 的Service ，ViewModel 可以根据Model 获取一个Bean的Observable( RxJava ),然后做一些数据转换操作和映射到ViewModel 中的一些字段，最后把这些字段绑定到View层上。 上面三部分的分工很明确，要不要把一部分逻辑放到activity 或者fragment来做是取决于你的提到的操作逻辑是什么，如果这些逻辑操作是可以通过修改数据(这些数据绑定到UI)来更改UI或者你的操作逻辑是业务逻辑或者修改数据，那么这块逻辑你完全可以在ViewModel 里面做。如果这些逻辑操作只是和UI有关，而且不能通过Binding的方式更改数据源去反馈到UI(比如说 简单的对话框、PopupWindow等)是可以考虑放到View层去做，但是如果这部分操作逻辑涉及到业务和数据相关的，那么建议不用放到View层做，View层主要职责是和UI相关的、没有数据，没有业务。
PS:该文章仅供自己学习之用！
.doc)
