前言

请预留足够的时间，您将看到大量的文字描述。但是相信我，您绝对值得花时间在这些文字描述上面。我已经尽了我最大所能来阐述关于MVC和MVVM如此这般设计的原因以及我们应该如何思考一些相关的问题

让我们从MVC开始

说起MVC，必须拿斯坦福大学公开课上的这幅图来说明，这可以说是最经典和最规范的MVC标准

所以看懂这张图，你就应该明白MVC在iOS中的实现思路了。

你一直在使用MVC的思想只是你可能没有察觉到

在我们着手探究MVC之前，有些东西是你应该了解的，虽然你可能已经了解了，但是这里还是要拿出来说一下，因为这些内容对于你理解MVC是如何运作的有很大的帮助。
几乎所有的App都只干这么一件事：将数据展示给用户看，并处理用户对界面的操作。
写过iOS App开发的开发者都知道我们大量的操作都是在controller中写布局代码再把数据显示到视图上面，然后实现一些专门处理用户操作的逻辑（比如按钮点击事件的实现）。
这里实际上你已经无形之中使用了MVC的思想了：一句话描述就是Controller负责将Model的数据用View显示出来，换句话说就是在Controller里面把Model的数据赋值给View，比如在controller中写self.label.text = self.data[@”title”]，只是还没有刻意建一个Model类出来而已。

MVC是如何进行工作的

简（xiang）单（xi）解释一下MVC所代表的意思（网上随处可见）

M：Model，数据模型，比如我们人类有一双手，一双眼睛，一个脑袋，没有尾巴，这就是模型，Model定义了这个模块的数据模型。在代码中体现为数据管理者，Model负责对数据进行获取及存放。数据不可能凭空生成的，要么是从服务器上面获取到的数据，要么是本地数据库中的数据，也有可能是用户在UI上填写的表单即将上传到服务器上面存放，所以需要有数据来源。既然Model是数据管理者，则自然由它来负责获取数据。Controller不需要关心Model是如何拿到数据的，只管调用就行了。数据存放的地方是在Model，而使用数据的地方是在Controller，所以Model应该提供接口供controller访问其存放的数据（通常通过.h里面的只读属性）。

V：View，视图，简单来说，就是我们在界面上看见的一切。大多数情况都是继承自UIView的类的对象，而有时候则不是直接继承自UIView，有时候会直接用CoreAnimation甚至CoreGraphics来绘制内容，但这些东西统统都归结为MVC中的View。它们有一部分是我们UI定死的，也就是不会根据数据来更新显示的，比如一些Logo图片啊，这里有个按钮啊，那里有个输入框啊，一些显示特定内容的label啊等等；有一部分是会根据数据来显示内容的，比如tableView来显示好友列表啊，这个tableView的显示内容肯定是根据数据来显示的。我们使用MVC解决问题的时候，通常是解决这些根据数据来显示内容的视图。这里要提个醒：MVC虽然看似把模块分为了三部分，但是并不是说一个模块就要一定建三个类出来，比如联系人列表（ContactsList）模块，一定会有的肯定是ContactsListViewController，然后我们使用MVC来作为内部的框架，则需要创建ContactsListModel类，接下来会有少年继续创建ContactsListView，他认为这才是MVC，有三个类分别是XXXModel、XXXController、XXXView，这就大错特错了，你们在Controller中使用的UILabel、UITableView等等就是MVC中的View了，不要再专门建一个XXXXView出来，完全是没事找事多此一举。

C：Controller，最熟悉却又最抽象的一个东西。之所以熟悉，我们在使用UIKit进行开发中我敢说是你打交道最多的类：UIViewController。UIKit框架离不开UIViewController，当然你完全可以使用UIView来完成所有本该由Controller完成的事情，这是大逆不道的，因为这样做将会使你的整个项目代码一团糟，并且完美的违背了面向对象的思想：各司其职。这里大家一定要知道UIViewController究竟应该做些什么事，实际上就是API提供出来的接口：self.view用来作为所有视图的容器；管理自己的生命周期；controller之间的转场；controller容器。这是Controller的本职工作，然而它往往还需要承担起MVC中的数据和视图的协调者，也就是在Controller里面把Model的数据赋值给View来显示（或者是View接收用户输入的数据然后由Controller把这些数据传给Model来保存到本地或者上传到服务器）。

综合以上内容，实际上你应该可以通过面向对象的基本思想来推导出controller出现的原因：我们所有的App都是界面和数据的交互，所以需要类来进行界面的绘制，于是出现了View，需要类来管理数据于是出现了Model。我们设计的View应该能显示任意的内容比如UILabel显示的文字应该是任意的而不只是某个特定Model的内容，所以我们不应该在View的实现中去写和Model相关的任何代码，如果这样做了，那么View的可扩展性就相当低了。而Model只是负责处理数据的，它根本不知道数据到时候会拿去干啥，可能拿去作为算法噼里啪啦去了，可能拿去显示给用户了，它既然无法接收用户的交互，它就不应该去管和视图相关的任何信息，所以Model中不应该写任何View相关代码。然而我们的数据和界面应该同步，也就是一定要有个地方要把Model的数据赋值给View，而Model内部和View的内部都不可能去写这样的代码，所以只能新创造一个类出来了，取名为Controller。它被UIKit逐渐完善成了我们现在使用的UIViewController。

看图说话

你要问我以上这么一大堆东西我是怎么知道的？我就完成了一次看图说话而已，我们终于要开始讲解这张图了，为了更好的观看体验，我再次向您呈现出这张图，这样你就不需要往上面翻一大段内容了。

duang!