因为习惯了MVC的开发模式，所以对这种对XML“瞎改”的做法相当的不习惯，更不要说理解MVVM到底是什么玩意了；现在定下心来看看MVVM代码的实现过程，还是觉得这是一个很了不起的架构。
我将在本文对MVC、MVP、MVVM三种结构进行对比说明，并在最后附上MVVM架构的代码例子，帮助大家了解这一框架的精髓
MVC
MVC全名是Model-View-Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑
Model：应用程序中用于处理应用程序数据逻辑的部分，它主要负责网络请求，数据库处理，I/O等的操作。
View：应用程序中处理数据显示的部分。在Android开发中，它一般对应着xml布局文件
Controller：应用程序中处理用户交互的部分，接受用户的输入并调用Model和View去完成用户的需求。在Android开发中一般由Activity或Fragment来承担
MVC架构肯定是有优点的，要不然这玩意不会有存在的意义。它通过Controller来掌控全局，同时将View展示和Model的变化分离开。但是对于Android开发来说，一旦一个页面的业务繁多复杂的话，Controller里的代码就会越来越臃肿，这是因为Activity或Fragment不仅仅要负责业务逻辑，同时还要加载应用的布局和初始化使用界面，也就是说Activity或Fragment杂糅了Controller和View的功能，这不能算作一个真正意义上的MVC。因此在这种情况下，MVP架构呼之欲出
MVP
MVP全名是Model-View-Presenter。MVP是从经典的MVC模式演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。
作为一种新的模式，MVP与MVC有着一个重大的区别：MVP中的View并不直接使用Model，它们之间的通信是通过Presenter(MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过Controller
Model：应用程序中用于处理应用程序数据逻辑的部分，它主要负责网络请求，数据库处理，I/O等的操作。
View：应用程序中处理数据显示的部分。在Android开发中，它一般对应着xml布局文件、Activity、Fragment
Presenter：整个MVP体系的控制中心，作为View与Model交互的中间纽带，处理View与Model间的交互和业务逻辑。
在Android开发中，MVP的具体实现流程是当Presenter接收到View的请求，便从Model层获取数据，将数据进行处理。处理好的数据再通过View层的接口回调给Activity或Fragment。这样MVP能够让Activity或Fragment成为真正的View，只做与UI相关的事而不处理其他业务流程。
综上所述，MVP的优点如下：
模型与视图完全分离，我们可以修改视图而不影响模型；
项目代码结构清晰，一看就知道什么类干什么事情；
我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化更频繁
协同工作（例如在设计师没出图之前可以先写一些业务逻辑代码）
MVP也有不足之处：
接口过多，一定程度影响了编码效率。
一定程度上导致Presenter的代码量过大。
为了降低Presenter中业务繁多的问题，Google又推出了MVVM，试图通过数据驱动来减少Presenter的代码量
MVVM
MVVM是Model-View-ViewModel的简写。它本质上就是MVC的改进版。MVVM就是将其中View的状态和行为抽象化，让我们将视图UI和业务逻辑分开。当然这些事 ViewModel已经帮我们做了，它可以取出Model的数据同时帮忙处理View中由于需要展示内容而涉及的业务逻辑
Model：应用程序中用于处理应用程序数据逻辑的部分，它主要负责网络请求，数据库处理，I/O等的操作。
View：应用程序中处理数据显示的部分。在Android开发中，它一般对应着xml布局文件、Activity、Fragment。
这里需要补充的是
View层负责处理UI相关的工作，我们只在XML、Activity和Fragment写View层的功能而不进行业务的处理，也就是说我们不在View层写业务逻辑和业务数据相关的代码。
ViewModel ：创建关联，将Model和View绑定起来。这样，一旦Model发生更改，ViewModel就会立即反馈给View从而自动刷新界面。
这里需要补充的是
ViewModel只负责业务逻辑，不做任何和UI相关的事情。更新UI通过数据绑定实现，尽量在ViewModel里面做
来看下MVVM架构在Android上的架构实现
综上所述，MVVM的优点如下：
数据驱动
在MVVM中，数据和业务逻辑处于一个独立的ViewModel中，ViewModel只要关注数据和业务逻辑，不需要和UI或者控件打交道。由数据自动去驱动UI去自动更新UI，UI的改变又同时自动反馈到数据，数据成为主导因素，这样使得在业务逻辑处理只要关心数据，方便而且简单很多。
低耦合度
MVVM模式中，数据是独立于UI的，ViewModel只负责处理和提供数据，UI想怎么处理数据都由UI自己决定，ViewModel不涉及任何和UI相关的事也不持有UI控件的引用
团队协作
MVVM的分工是非常明显的，由于View和ViewModel之间是松散耦合的。一个是处理业务和数据，一个是专门的UI处理，所以完全可以由两个人分工来做，一个做UI（xml 和 Activity）一个写ViewModel，效率更高。
可复用性
一个ViewModel可以复用到多个View中。同样的一份数据，用不同的UI去做展示，对于版本迭代频繁的UI改动，只要更换View层就行
单元测试
ViewModel里面是数据和业务逻辑，View中关注的是UI，这样做测试是很方便的，完全没有彼此依赖，不管是UI的单元测试还是业务逻辑的单元测试，都是低耦合的。
MVVM的缺点：
更加大的学习成本。目前这种架构的实现方式比较不完善，常见的就是通过DataBinding来完成。
数据绑定使得调试变得困难。当你看到界面异常，有可能是你View的代码有Bug，也可能是Model的代码有问题。数据绑定使得一个位置的Bug被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。
数据双向绑定不利于代码重用。客户端开发最常用的重用是View，但是数据双向绑定技术让你的一个View都绑定了一个model，不同模块的model都不同
既然说到DataBinding，那我们就简单了解下它吧
DataBinding
DataBinding早在2015年的Google I/O大会上就被推出了，从名字就可以得知它是一个实现数据和UI绑定的框架。它是构建MVVM架构的一个关键工具，它支持数据和UI双向绑定。
什么是双向绑定？通常情况下，数据的流向是单方面的，只能从业务逻辑处理后流向UI，这就是单向绑定。而双向绑定模式下，数据流向是双向的。业务逻辑中的数据改变时，UI上的数据能够得到刷新；而当用户通过UI交互编辑了数据后，数据也能自动更新到相应的数据源上。
在实际Android开发中，针对Activity或Fragment的布局，在编译阶段会生成一个ViewDataBinding类的对象，该对象持有Activity或Fragment中要展示的数据以及布局中的各个view的引用。当程序运行之后，它将数据分解到各个View上，在UI线程上更新数据、监控数据的变化。这样一来，要展示的数据以及布局就被紧紧的绑定在了一起。
示例代码
终于到了紧张刺激的时刻了，让我们一起看看MVVM架构的代码是如何实现的吧。
先看看项目结构。我这里使用的是DataBinding+Dagger2，所以自上而下的分别是dagger2的包以及DataBinding的包。DataBinding除了m，v，vm以外，还简单封装了一下BaseActivity与BaseAdapter，并将事件Model接口单独放在EventListener中，同时将网络请求放到NetRequest里面
下面来具体看代码吧
先看看Application，这个没啥，定义了OkHttpClient请求对象。注意因为是kotlin，所以client对象转成Java之后作用于不再是public而是变成private，dagger2不能赋值给private对象，所以要在其上方加@JvmField注解
class MyApplication : Application() {
@JvmField
@Inject
var client: OkHttpClient? = null
override fun onCreate() {
super.onCreate()
DaggerAppComponent.builder().appModule(AppModule(this)).build().injectApp(this)
}
}
网络请求部分，写了一个单例。getRequestInfo()就是后续请求的Observable
class NetRequest private constructor() {
companion object {
@Volatile private var INSTANCE: NetRequest? = null
fun getInstance(): NetRequest {
return INSTANCE ?: synchronized(NetRequest::class) {
INSTANCE ?: NetRequest()
}
}
}
fun getRequestInfo() : Observable {
return Observable.create {
val builder = Request.Builder()
val request = builder.url("http://www.mocky.io/v2/5afe76b83200007400222e7b").build()
val call = (Utils.getApp() as MyApplication).client!!.newCall(request)
val response = call.execute()
if (response.isSuccessful) {
it.onNext(response.body()!!.string())
}
else {
it.onError(Exception("出现异常"))
}
}.subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread())
}
}
事件部分，后续给Activity实现
interface EventListener {
fun onClickListener(view: View, value: String)
}
先来看看m
class SearchBeans : BaseObservable() {
var value: String? = null
@Bindable
get() = field
set(value) {
field = value
notifyPropertyChanged(BR.value)
}
var position: Int? = null
@Bindable
get() = field
set(value) {
field = value
notifyPropertyChanged(BR.position)
}
}
在ViewModel里面进行网络请求，得到结果之后通过EventBus传递到Activity中。ViewModel的理解因人而异，我之前还看到过把ViewModel跟Model混在一起的写法，我觉得都是不对的。甚至还见过把网络请求又写在Activity中的代码，这个都是违背了MVVM本质了。我没有将请求部分放置在Model中，这是因为独立的网络类可以方便我后续的管理
class SearchViewModel {
fun getRemoteValue() {
NetRequest.getInstance().getRequestInfo().subscribe({
val type = object : TypeToken>() {}.type
val value = Gson().fromJson>(it, type)
EventBus.getDefault().post(value)
}, {
}, {
})
}
}
剩下重头戏View部分了，来看看xml部分。先来看看Activity的布局，里面有一个RecyclerView，它的Model是一个Adapter，还有一个自定义属性app:adapter
自定义属性我是放在Utils工具类里面，在这里对RecyclerView进行adapter的绑定
class Utils {
companion object {
@JvmStatic
@BindingAdapter("adapter")
fun setAdapter(recyclerView: RecyclerView, adapter: SearchAdapter) {
recyclerView.layoutManager = LinearLayoutManager(recyclerView.context)
recyclerView.setHasFixedSize(true)
recyclerView.adapter = adapter
}
}
}
来看看Activity的实现，BaseActivity在onCreate()中将View和Model进行绑定
abstract class BaseActivity : AppCompatActivity() {
abstract fun initViews(): Int
abstract fun variableId(): Int
abstract fun model(): M
abstract fun viewModel() : VM
abstract fun initParams()
abstract fun loadData()
var viewDataBinding: T? = null
var viewModel: VM? = null
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
viewDataBinding = DataBindingUtil.setContentView(this, initViews())
viewDataBinding?.setVariable(variableId(), model())
viewModel = viewModel()
initParams()
loadData()
}
}
真正实现部分，看看这里是不是只对UI进行处理了？viewModel?.getRemoteValue()去获取远程数据，通过EventBus获取得到的结果。这里实现了EventListener接口并将其传给Adapter
class SearchActivity : BaseActivity(), EventListener {
private val beans: ArrayList by lazy {
ArrayList()
}
private val adapter: SearchAdapter by lazy {
SearchAdapter(beans, this)
}
override fun onClickListener(view: View, value: String) {
val intent = Intent(this, DetailActivity::class.java)
intent.putExtra("key", value)
startActivity(intent)
}
override fun initViews() = R.layout.activity_search
override fun variableId() = BR.adapter
override fun model() = adapter
override fun viewModel() = SearchViewModel()
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
EventBus.getDefault().register(this)
}
override fun initParams() {
}
override fun loadData() {
viewDataBinding?.rvSearch?.post {
viewModel?.getRemoteValue()
}
}
override fun onDestroy() {
super.onDestroy()
EventBus.getDefault().unregister(this)
}
@Subscribe(threadMode = ThreadMode.MAIN)
fun onEventMainThread(bean: List) {
beans.addAll(bean)
adapter.notifyDataSetChanged()
}
}
来看看Adapter部分。这里面也是对EventListener以及每一行Item对应的对象SearchBeans的声明
BaseAdapter里面完成了View跟Model的绑定，这个还包含对EventListener的绑定
abstract class BaseAdapter(val beans: ArrayList, private val eventListener: EventListener) : RecyclerView.Adapter() {
abstract fun initViews(): Int
abstract fun dataVariableId(): Int
abstract fun eventListenerVariableId(): Int
override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): BaseViewHolder {
val viewDataBinding = DataBindingUtil.inflate(LayoutInflater.from(parent.context), initViews(), parent, false)
return BaseViewHolder(viewDataBinding)
}
override fun getItemCount(): Int = beans.size
override fun onBindViewHolder(holder: BaseViewHolder, position: Int) {
holder.viewDataBinding?.setVariable(dataVariableId(), beans[holder.layoutPosition])
holder.viewDataBinding?.setVariable(eventListenerVariableId(), eventListener)
holder.viewDataBinding?.executePendingBindings()
}
class BaseViewHolder : RecyclerView.ViewHolder {
var viewDataBinding: ViewDataBinding? = null
constructor(viewDataBinding: ViewDataBinding) : super(viewDataBinding.root) {
this.viewDataBinding = viewDataBinding
}
}
}
真正实现部分倒没多少代码
class SearchAdapter(beans: ArrayList, eventListener: EventListener) : BaseAdapter(beans, eventListener) {
override fun dataVariableId(): Int {
return BR.beans
}
override fun eventListenerVariableId(): Int {
return BR.eventListener
}
override fun initViews() = R.layout.adapter_search
}
剩下就完成了，看看有没有毛病
总结一下，以上三种框架没有一个能说一定是最好的，关键还是看你自己的选择。说老实话，就为了一个列表，我看MVC比MVVM和MVP实现起来都轻松。但是如果你写一个大首页的话，最好还是采取MVVM或者MVP，为了方便自己后续修改调试，也方便将来给你擦屁股的那个朋友