前言：
·在iOS开发中，大部分使用的都是MVC架构，虽然MVC层次明确，但是由于功能、代码量日益增加，更多的代码被写在了controller中，这样controller就显得非常臃肿。
简单来说，MVVM的横空出世是为了解决MVC模式下的viewcontroller”瘦身”。
在MVC模式下，有一个显著不好的地方，就是viewcontroller即C层，有人称之为Massive View Controller（臃肿的视图控制器），为什么称之为臃肿的视图控制器?原因其实很简单，我们一直都把数据请求服务层放到controller，包括一些业务逻辑等将其放在controller，这使得controller代码量很多，这些堆积的代码几乎不被共用，而且维护性很差。
*MVC：
MVC架构图
这里controller需要做太多的工作，业务逻辑，网络请求等，代码量非常大。
*MVVM：
MVVM架构图
我们都知道，在ios这边，controller(控制器)的全称是viewcontroller(视图控制器)。既然是视图控制器，那么controller就专门负责管理视图即可，其他的工作就不用负责，在其位某其职即可。那么问题来了，数据请求、业务逻辑层谁负责呢？MVVM就专门构造ViewModel这么一个实体去负责数据请求、业务逻辑这些事情。那么MVVM的具体概念就出来了。
M : 必不可少的Model层，负责数据的存储
V ： viewcontroller，负责管理视图（自定义）
VM : viewModel,专门负责数据请求、业务逻辑等业务。
*关于对MVVM的一些评价：
MVVM 的作者 John Gossman 的 批评 应该是最为中肯的。John Gossman 对 MVVM 的批评主要有两点：
第一点：数据绑定使得 Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了
第二点：对于过大的项目，数据绑定需要花费更多的内存。MVVM 在使用当中，通常还会利用双向绑定技术，使得 Model 变化时，ViewModel 会自动更新，而 ViewModel 变化时，View 也会自动变化。所以，MVVM 模式有些时候又被称作：model-view-binder 模式。
网友评论