面试之路（3）-详解MVC，MVP，MVVM

一：mvc

mvc结构：

视图（View）：用户界面。

控制器（Controller）：业务逻辑

模型（Model）：数据保存

mvc各部分的通信方式

mvc互动模式

通过 View 接受指令，传递给 Controller。



另一种是直接通过controller接受指令。

mvc的历史

MVC 的概念最早出现在二十世纪八十年代的 施乐帕克 实验室中（对，就是那个发明图形用户界面和鼠标的实验室），当时施乐帕克为 Smalltalk 发明了这种软件设计模式。

controller层的臃肿问题

于 View 来说，你如果抽象得好，那么一个 App 的动画效果可以很方便地移植到别的 App 上。

对于 Model 来说，它其实是用来存储业务的数据的，如果做得好，它也可以方便地复用。

如果我们能够意识到 Controller 里面的代码不便于复用，我们就能知道什么代码应该写在 Controller 里面了，那就是那些不能复用的代码。

一个解决的思路

Controller 里面就只应该存放这些不能复用的代码，这些代码

在初始化时，构造相应的 View 和 Model。
监听 Model 层的事件，将 Model 层的数据传递到 View 层。
监听 View 层的事件，并且将 View 层的事件转发到 Model 层。

Controller 只有以上的这些代码，那么它的逻辑将非常简单，而且也会非常短。

controller进一步的解决方案

但是，我们却很难做到这一点，因为还是有很多逻辑我们不知道写在哪里，于是就都写到了 Controller 中了，那我们接下来就看看其它逻辑应该写在哪里。

将 UITableView 的 Data Source 分离到另外一个类中。
将数据获取和转换的逻辑分别到另外一个类中。
将拼装控件的逻辑，分离到另外一个类中。

具体包括一下几种解决方案：

将网络请求抽象到单独的类中

将界面的拼装抽象到专门的类中

构造 ViewModel

这样抽象之后，View 只接受 ViewModel，而 Controller 只需要传递 ViewModel 这么一行代码。而另外构造 ViewModel 的过程，我们就可以移动到另外的类中了。

专门构造存储类

二：MVP

MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。



1. 各部分之间的通信，都是双向的。

2. View 与 Model 不发生联系，都通过 Presenter 传递。

3. View 非常薄，不部署任何业务逻辑，称为”被动视图”（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。

三：MVVM

MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。

MVVM的历史

相对于 MVC 的历史来说，MVVM 是一个相当新的架构，MVVM 最早于 2005 年被微软的 WPF 和 Silverlight 的架构师 John Gossman 提出，并且应用在微软的软件开发中。当时 MVC 已经被提出了 20 多年了，可见两者出现的年代差别有多大。

MVVM的问题

MVVM 的作者 John Gossman 的 批评 应该是最为中肯的。John Gossman 对 MVVM 的批评主要有两点：

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

第二点：对于过大的项目，数据绑定需要花费更多的内存。

本篇文章是在读唐巧和阮一峰的博客后总结成的，许多地方直接复制粘贴了（链接如下）

http://blog.devtang.com/2015/11/02/mvc-and-mvvm/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

http://www.ruanyifeng.com/blog/2015/02/mvcmvp_mvvm.html?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io