iOS面试题：MVVM和MVC的区别

MVVM和MVC的区别

1. MVC

MVC的弊端git

厚重的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的问题。若不这样，何处才是网络逻辑的家呢？github

较差的可测试性

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

2. MVVM

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

2.1 MVVM 的基本概念

在MVVM 中，view 和 view controller正式联系在一块儿，咱们把它们视为一个组件
view 和 view controller 都不能直接引用model，而是引用视图模型（viewModel）
viewModel 是一个放置用户输入验证逻辑，视图显示逻辑，发起网络请求和其余代码的地方
使用MVVM会轻微的增长代码量，但整体上减小了代码的复杂性

2.2 MVVM 的注意事项

view 引用viewModel ，但反过来不行（即不要在viewModel中引入#import UIKit.h，任何视图自己的引用都不该该放在viewModel中）（PS：基本要求，必须知足）
viewModel 引用model，但反过来不行* MVVM 的使用建议
MVVM 能够兼容你当下使用的MVC架构。
MVVM 增长你的应用的可测试性。
MVVM 配合一个绑定机制效果最好（PS：ReactiveCocoa你值得拥有）。
viewController 尽可能不涉及业务逻辑，让 viewModel 去作这些事情。
viewController 只是一个中间人，接收 view 的事件、调用 viewModel 的方法、响应 viewModel 的变化。
viewModel 绝对不能包含视图 view（UIKit.h），否则就跟 view 产生了耦合，不方便复用和测试。
viewModel之间能够有依赖。
viewModel避免过于臃肿，不然重蹈Controller的覆辙，变得难以维护。

2.3 MVVM 的优点

低耦合：View 能够独立于Model变化和修改，一个 viewModel 能够绑定到不一样的 View 上
可重用性：能够把一些视图逻辑放在一个 viewModel里面，让不少 view 重用这段视图逻辑
独立开发：开发人员能够专一于业务逻辑和数据的开发 viewModel，设计人员能够专一于页面设计
可测试：一般界面是比较难于测试的，而 MVVM 模式能够针对 viewModel来进行测试

2.4 MVVM 的弊端

数据绑定使得Bug 很难被调试。你看到界面异常了，有多是你 View 的代码有 Bug，也多是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。
对于过大的项目，数据绑定和数据转化须要花费更多的内存（成本）。主要成本在于：
数组内容的转化成本较高：数组里面每项都要转化成Item对象，若是Item对象中还有相似数组，就很头疼。
转化以后的数据在大部分状况是不能直接被展现的，为了可以被展现，还须要第二次转化。
只有在API返回的数据高度标准化时，这些对象原型（Item）的可复用程度才高，不然容易出现类型爆炸，提升维护成本。
调试时经过对象原型查看数据内容不如直接经过NSDictionary/NSArray直观。
同一API的数据被不一样View展现时，难以控制数据转化的代码，它们有可能会散落在任何须要的地方。

3. 总结

MVC的设计模式也并不是是病入膏肓，无药可救的架构，最起码目前MVC设计模式仍旧是iOS开发的主流框架，存在即合理。针对文章所述的弊端，咱们依旧有许多可行的方法去避免和解决，从而打造一个轻量级的ViewController。
MVVM是MVC的升级版，彻底兼容当前的MVC架构，MVVM虽然促进了UI 代码与业务逻辑的分离，必定程度上减轻了ViewController的臃肿度，可是View和ViewModel之间的数据绑定使得 MVVM变得复杂和难用了，若是咱们不能更好的驾驭二者之间的数据绑定，一样会形成Controller 代码过于复杂，代码逻辑不易维护的问题。
一个轻量级的ViewController是基于MVC和MVVM模式进行代码职责的分离而打造的。MVC和MVVM有优势也有缺点，但缺点在他们所带来的好处面前时不值一提的。他们的低耦合性，封装性，可测试性，可维护性和多人协做便利大大提升了开法效率。
同时，咱们须要保持的是一个拥抱变化的心，以及理性分析的态度。在新技术的面前，不盲从，也不守旧，一切的决策都应该创建在认真分析的基础上，这样才能应对技术的变化。

更多：iOS面试题合集设计模式