1.MVVM和MVC的区别

MVC:

MVC的弊端

厚重的View Controller

M：模型model的对象通常非常的简单。根据Apple的文档，model应包括数据和操作数据的业务逻辑。而在实践中，model层往往非常薄，不管怎样，model层的业务逻辑不应被拖入到controller。

V：视图view通常是UIKit控件（component，这里根据习惯译为控件）或者编码定义的UIKit控件的集合。View的如何构建（PS：IB或者手写界面）何必让Controller知晓，同时View不应该直接引用model（PS：现实中，你懂的！），并且仅仅通过IBAction事件引用controller。业务逻辑很明显不归入view，视图本身没有任何业务。

C：控制器controller。Controller是app的“胶水代码”：协调模型和视图之间的所有交互。控制器负责管理他们所拥有的视图的视图层次结构，还要响应视图的loading、appearing、disappearing等等，同时往往也会充满我们不愿暴露的model的模型逻辑以及不愿暴露给视图的业务逻辑。网络数据的请求及后续处理，本地数据库操作，以及一些带有工具性质辅助方法都加大了Massive View Controller的产生。

遗失（无处安放）的网络逻辑

苹果使用的MVC的定义是这么说的：所有的对象都可以被归类为一个model，一个view，或是一个controller。

你可能试着把它放在Model对象里，但是也会很棘手，因为网络调用应该使用异步，这样如果一个网络请求比持有它的model生命周期更长，事情将变的复杂。显然View里面做网络请求那就更格格不入了，因此只剩下Controller了。若这样，这又加剧了Massive View Controller的问题。若不这样，何处才是网络逻辑的家呢？

较差的可测试性

由于View Controller混合了视图处理逻辑和业务逻辑，分离这些成分的单元测试成了一个艰巨的任务。

2. MVVM

一种可以很好地解决Massive View Controller问题的办法就是将 Controller 中的展示逻辑抽取出来，放置到一个专门的地方，而这个地方就是viewModel。MVVM衍生于MVC，是对 MVC 的一种演进，它促进了 UI 代码与业务逻辑的分离。它正式规范了视图和控制器紧耦合的性质，并引入新的组件。他们之间的结构关系如下：

MVVM

MVVM 的基本概念

在MVVM中，view和view controller正式联系在一起，我们把它们视为一个组件

view和view controller都不能直接引用model，而是引用视图模型（viewModel）

viewModel是一个放置用户输入验证逻辑，视图显示逻辑，发起网络请求和其他代码的地方

使用MVVM会轻微的增加代码量，但总体上减少了代码的复杂性

MVVM 的实现方式原理

让Controller拥有View和ViewModel属性，VM拥有Model属性；Controller或者View来接收ViewModel发送的Model改变的通知

用户的操作点击或者Controller的视图生命周期里面让ViewModel去执行请求，请求完成后ViewModel将返回数据模型化并保存，从而更新了Model；Controller和View是属于V部分，即实现V改变M（V绑定M）。如果不需要请求，这直接修改Model就是了。

第2步中的Model的改变，VM是知道的（因为持有关系），只需要Model改变后发一个通知；Controller或View接收到通知后（一般是Controller先接收再赋值给View），根据这个新Model去改变视图就完成了M改变V（M绑定V）

好慷在家3.0APP-MVVM 的实现

1.这边我们引用三方库RXSwift来辅助实现MVVM设计模式

2.我们先让VC拥有View跟ViewModel对象:

VC中通过RXSwift定义一个dataArr数组用来存储VM中返回的接口数据

将dataArr数组绑定在表格的代理方法中达到监听model数据同时改变tableView样式

3.ViewModel定义请求的接口数据及处理接口数据的展示逻辑,这边VM中接口请求用RXSwift的方法observe.onNext触发监听机制让V接收

4.将dataArr中存储的model数据代入到View中渲染视图,同时视图的操作也改变model的值达到同步改变VC中的dataArr数据