iOS MVC的弊端以及对MVVM架构的理解

最近准备开启新的一个项目，想尝试使用另一种架构，因为上个电商项目，用的是MVC架构，发现自己的一些代码写的有些臃肿，特别是购物车界面有很多的业务逻辑，代码很多都集合在了controller，本着让代码清晰，耦合度低，便于测试的原则，对新的架构模式mvvm在网上进行了相关博客和源代码的研究。

一.MVC的弊端

MVC的利弊大家想必是有目共睹的，Massive View Controller的说法也并非空穴来风的。让我们一起探讨MVC的弊端，剖析问题产生原因，打造一个轻量级的ViewController，明确MVC设计模式中各个角色的职责。

厚重的View Controller

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

V：视图view通常是UIKit控件或者编码定义的UIKit控件的集合。View的如何构建何必让Controller知晓，同时View不应该直接引用model。业务逻辑很明显不归入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混合了视图处理逻辑和业务逻辑，分离这些成分的单元测试成了一个艰巨的任务。若一个Massive View Controller有上万行代码，要你编写个单元测试能不把你累死也会气死.

二、MVVM（Model View View-Mode）

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

他们之间的结构关系如下：

0

MVVM 的基本概念

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

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

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

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

MVVM 的注意事项:

view 引用viewModel ，但反过来不行（即不要在viewModel中引入#import UIKit.h，任何视图本身的引用都不应该放在viewModel中）注意：基本要求，必须满足）

viewModel 引用model，但反过来不行

MVVM 的使用建议:

MVVM 可以兼容你当下使用的MVC架构。

MVVM 增加你的应用的可测试性。

MVVM 配合一个绑定机制效果最好（PS：ReactiveCocoa你值得拥有）。

viewController 尽量不涉及业务逻辑，让 viewModel 去做这些事情。

viewController 只是一个中间人，接收 view 的事件、调用 viewModel 的方法、响应 viewModel 的变化。

viewModel 绝对不能包含视图 view（UIKit.h），不然就跟 view 产生了耦合，不方便复用和测试。

viewModel之间可以有依赖。

viewModel避免过于臃肿，否则重蹈Controller的覆辙，变得难以维护。

MVVM 的优势

低耦合：View 可以独立于Model变化和修改，一个 viewModel 可以绑定到不同的 View 上

可重用性：可以把一些视图逻辑放在一个 viewModel里面，让很多 view 重用这段视图逻辑

独立开发：开发人员可以专注于业务逻辑和数据的开发 viewModel，设计人员可以专注于页面设计

可测试：通常界面是比较难于测试的，而 MVVM 模式可以针对 viewModel来进行测试

MVVM 的弊端

数据绑定使得Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。

对于过大的项目，数据绑定和数据转化需要花费更多的内存（成本）。主要成本在于：

数组内容的转化成本较高：数组里面每项都要转化成Item对象，如果Item对象中还有类似数组，就很头疼。

转化之后的数据在大部分情况是不能直接被展示的，为了能够被展示，还需要第二次转化。

只有在API返回的数据高度标准化时，这些对象原型（Item）的可复用程度才高，否则容易出现类型爆炸，提高维护成本。

调试时通过对象原型查看数据内容不如直接通过NSDictionary/NSArray直观。

同一API的数据被不同View展示时，难以控制数据转化的代码，它们有可能会散落在任何需要的地方。

三、案例理解

当然，与其专注于说明 MVVM 的来历，不如让我们看一个典型的 iOS 是如何构建的，并从那里了解 MVVM：

1

我们看到的是一个典型的 MVC 设置。Model 呈现数据，View 呈现用户界面，而 View Controller 调节它两者之间的交互。Cool！

稍微考虑一下，虽然 View 和 View Controller 是技术上不同的组件，但它们几乎总是手牵手在一起，成对的。你什么时候看到一个 View 能够与不同 View Controller 配对？或者反过来？所以，为什么不正规化它们的连接呢？

2

这更准确地描述了你可能已经编写的 MVC 代码。但它并没有做太多事情来解决 iOS 应用中日益增长的重量级视图控制器的问题。在典型的 MVC 应用里，许多逻辑被放在 View Controller 里。它们中的一些确实属于 View Controller，但更多的是所谓的“表示逻辑（presentation logic）”，以 MVVM 属术语来说，就是那些将 Model 数据转换为 View 可以呈现的东西的事情，例如将一个 NSDate 转换为一个格式化过的 NSString。

我们的图解里缺少某些东西，那些使我们可以把所有表示逻辑放进去的东西。我们打算将其称为 “View Model” —— 它位于 View/Controller 与 Model 之间：

3

看起好多了！这个图解准确地描述了什么是 MVVM：一个 MVC 的增强版，我们正式连接了视图和控制器，并将表示逻辑从 Controller 移出放到一个新的对象里，即 View Model。MVVM 听起来很复杂，但它本质上就是一个精心优化的 MVC 架构，而 MVC 你早已熟悉。

现在我们知道了什么是 MVVM，但为什么我们会想要去使用它呢？在 iOS 上使用 MVVM 的动机，对我来说，无论如何，就是它能减少 View Controller 的复杂性并使得表示逻辑更易于测试。通过一些例子，我们将看到它如何达到这些目标。

此处有三个重点是我希望你看完本文能带走的：

MVVM 可以兼容你当下使用的 MVC 架构。

MVVM 增加你的应用的可测试性。

MVVM 配合一个绑定机制效果最好。

如我们之前所见，MVVM 基本上就是 MVC 的改进版，所以很容易就能看到它如何被整合到现有使用典型 MVC 架构的应用中。让我们看一个简单的 Person Model 以及相应的 View Controller：

4

Cool！现在我们假设我们有一个 PersonViewController ，在 viewDidLoad 里，只需要基于它的 model 属性设置一些 Label 即可。

5

这全都直截了当，标准的 MVC。现在来看看我们如何用一个 View Model 来增强它。

6

我们的 View Model 的实现大概如下：

7

Cool！我们已经将 viewDidLoad 中的表示逻辑放入我们的 View Model 里了。此时，我们新的 viewDidLoad就会非常轻量：

8

所以，如你所见，并没有对我们的 MVC 架构做太多改变。还是同样的代码，只不过移动了位置。它与 MVC 兼容，带来更轻量的 View Controllers。

可测试，嗯？是怎样？好吧，View Controller 是出了名的难以测试，因为它们做了太多事情。在 MVVM 里，我们试着尽可能多的将代码移入 View Model 里。测试 View Controller 就变得容易多了，因为它们不再做一大堆事情，并且 View Model 也非常易于测试。让我们来看看：

9

如果我们没有将这个逻辑移入 View Model，我们将不得不实例化一个完整的 View Controller 以及伴随的 View，然后去比较我们 View 中 Label 的值。这样做不只是会变成一个麻烦的间接层，而且它只代表了一个十分脆弱的测试。现在，我们可以按意愿自由地修改视图层级而不必担心破坏我们的单元测试。使用 MVVM 带来的对于测试的好处非常清晰，甚至从这个简单的例子来看也可见一斑，而在有更复杂的表示逻辑的情况下，这个好处会更加明显。

注意到在这个简单的例子中， Model 是不可变的，所以我们可以只在初始化的时候指定我们 View Model 的属性。对于可变 Model，我们还需要使用一些绑定机制，这样 View Model 就能在背后的 Model 改变时更新自身的属性。此外，一旦 View Model 上的 Model 发生改变，那 View 的属性也需要更新。Model 的改变应该级联向下通过 View Model 进入 View。

四、最后

MVVM是MVC的升级版，完全兼容当前的MVC架构，MVVM虽然促进了UI 代码与业务逻辑的分离，一定程度上减轻了ViewController的臃肿度，但是View和ViewModel之间的数据绑定使得 MVVM变得复杂和难用了，如果我们不能更好的驾驭两者之间的数据绑定，同样会造成Controller 代码过于复杂，代码逻辑不易维护的问题。

一个轻量级的ViewController是基于MVC和MVVM模式进行代码职责的分离而打造的。MVC和MVVM有优点也有缺点，但缺点在他们所带来的好处面前时不值一提的。他们的低耦合性，封装性，可测试性，可维护性和多人协作便利大大提高了开法效率。

同时，我们需要保持的是一个拥抱变化的心，以及理性分析的态度。在新技术的面前，不盲从，也不守旧，一切的决策都应该建立在认真分析的基础上，这样才能应对技术的变化。

参考:

通俗易懂:https://www.jianshu.com/p/a0c22492a620

https://www.jianshu.com/p/db8400e1d40e

https://blog.csdn.net/perfect_app/article/details/56007030

https://objccn.io/issue-13-1/

https://blog.csdn.net/u011171043/article/details/50593258

http://www.cocoachina.com/ios/20170710/19801.html