iOS面试题：MVVM和MVC的区别

MVVM和MVC的区别

1. 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

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猿_员
连接：https://www.jianshu.com/p/d0bc12a63ccf

给你们推荐一个iOS技术交流群，群内提供数据结构与算法、底层进阶、swift、逆向、底层面试题整合文档等免费资料！！！

可加我微信邀请你们进群