框架篇—MVC、MVP、MVCS、MVVM、VIPER使用关系总结

MVC MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。

MVC

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

数据关系

View 接受用户交互请求

View 将请求转交给Controller

Controller 操作Model进行数据更新

数据更新之后，Model通知View更新数据变化

View 更新变化数据

方式

所有方式都是单向通信

结构实现

View ：使用 Composite模式

View和Controller：使用 Strategy模式

Model和 View：使用 Observer模式同步信息

使用

MVC中的View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。所以，在MVC模型里，Model不依赖于View，但是 View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。

MVP

mvp的全称为Model-View-Presenter，Model提供数据，View负责显示，Controller/Presenter负责逻辑的处理。MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过 Controller。

数据关系

View 接收用户交互请求

View 将请求转交给 Presenter

Presenter 操作Model进行数据更新

Model 通知Presenter数据发生变化

Presenter 更新View数据

MVP的优势

Model与View完全分离，修改互不影响

更高效地使用，因为所有的逻辑交互都发生在一个地方—Presenter内部

一个Preseter可用于多个View，而不需要改变Presenter的逻辑(因为View的变化总是比Model的变化频繁)。

更便于测试。把逻辑放在Presenter中，就可以脱离用户接口来测试逻辑(单元测试)

方式

各部分之间都是双向通信

结构实现

View ：使用 Composite模式

View和Presenter：使用 Mediator模式

Model和Presenter：使用 Command模式同步信息

MVC和MVP区别

MVP与MVC最大的一个区别就是：Model与View层之间倒底该不该通信(甚至双向通信)

MVC和MVP关系

MVP：是MVC模式的变种。

项目开发中，UI是容易变化的，且是多样的，一样的数据会有N种显示方式；业务逻辑也是比较容易变化的。为了使得应用具有较大的弹性，我们期望将UI、逻辑(UI的逻辑和业务逻辑)和数据隔离开来，而MVP是一个很好的选择。

Presenter代替了Controller，它比Controller担当更多的任务，也更加复杂。Presenter处理事件，执行相应的逻辑，这些逻辑映射到Model操作Model。那些处理UI如何工作的代码基本上都位于Presenter。

MVC中的Model和View使用Observer模式进行沟通；MPV中的Presenter和View则使用Mediator模式进行通信；Presenter操作Model则使用Command模式来进行。基本设计和MVC相同：Model存储数据，View对Model的表现，Presenter协调两者之间的通信。在 MVP 中 View 接收到事件，然后会将它们传递到 Presenter, 如何具体处理这些事件，将由Presenter来完成。

如果要实现的UI比较复杂，而且相关的显示逻辑还跟Model有关系，就可以在View和 Presenter之间放置一个Adapter。由这个 Adapter来访问Model和View，避免两者之间的关联。而同时，因为Adapter实现了View的接口，从而可以保证与Presenter之 间接口的不变。这样就可以保证View和Presenter之间接口的简洁，又不失去UI的灵活性。

使用

MVP的实现会根据View的实现而有一些不同，一部分倾向于在View中放置简单的逻辑，在Presenter放置复杂的逻辑；另一部分倾向于在presenter中放置全部的逻辑。这两种分别被称为：Passive View和Superivising Controller。

MVVM

MVVM是Model-View-ViewModel的简写。微软的WPF带来了新的技术体验，如Silverlight、音频、视频、3D、动画……，这导致了软件UI层更加细节化、可定制化。同时，在技术层面，WPF也带来了 诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM(Model-View-ViewModel)框架的由来便是MVP(Model-View-Presenter)模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性糅合进去，以应对客户日益复杂的需求变化。

数据关系

View 接收用户交互请求

View 将请求转交给ViewModel

ViewModel 操作Model数据更新

Model 更新完数据，通知ViewModel数据发生变化

ViewModel 更新View数据

方式

双向绑定。View/Model的变动，自动反映在 ViewModel，反之亦然。

使用

可以兼容你当下使用的 MVC/MVP 框架。

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

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

MVVM优点

MVVM模式和MVC模式一样，主要目的是分离视图(View)和模型(Model)，有几大优点:

1. 低耦合。View可以独立于Model变化和修改，一个ViewModel可以绑定到不同的”View”上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。

2. 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。

3. 独立开发。开发人员可以专注于业务逻辑和数据的开发(ViewModel)，设计人员可以专注于页面设计，生成xml代码。

4. 可测试。界面素来是比较难于测试的，而现在测试可以针对ViewModel来写。

mvc,mvp,mvvm三者演化

说明

任何的项目框架，都是为项目服务的。没有绝对的好坏之分，只有更合适的选择。在项目进展的不同阶段，做出最合适的调整，才是是更适合团队项目发展的框架。项目设计者要谨记，任何的项目设计，都是要围绕项目发展阶段，团队成员规模，和团队整体能力而定的。切莫为了设计而设计，为了框架而框架。快速，高效的配合整个团队进展项目，才是最合适的架构。才是一个程序员为成一个leader，成为一个架构师的必经之路。

对于设计模式的学习是一件容易上瘾的事情，所以先提醒你一下：在你读完这篇文章之后，可能会比读之前有更多的疑问，比如：

(MVC)谁来负责网络请求：是 Model 还是 Controller？

(MVVM)我该怎么去把一个 Model 传递给一个新创建的 View 的 ViewModel？

(VIPER)谁来负责创建 VIPER 模块：是 Router 还是 Presenter？

为何要在意架构的选择呢？

因为如果你不在意的话，难保一天，你就需要去调试一个巨大无比又有着各种问题的类，然后你会发现在这个类里面，你完全就找不到也修复不了任何 bug。一般来说，把这么大的一个类作为整体放在脑子里记着是一件非常困难的事情，你总是难免会忘掉一些比较重要的细节。如果你发现在你的应用里面已经开始出现这种状况了，那你很可能遇到过下面这类问题：

这个类是一个 UIViewController 的子类。

你的数据直接保存在了 UIViewController 里面。

你的 UIViews 好像什么都没做。

你的 Model 只是一个纯粹的数据结构

你的单元测试什么都没有覆盖到

其实即便你遵循了 Apple 的设计规范，实现了Apple 的 MVC 框架，也还是一样会遇到上面这些问题；所以也没什么好失落的。Apple 的 MVC 框架有它自身的缺陷，不过这个我们后面再说。

让我们先来定义一下好的框架应该具有的特征：

用严格定义的角色，平衡的将职责划分给不同的实体。

可测性通常取决于上面说的第一点(不用太担心，如果架构何时的话，做到这点并不难)。

易用并且维护成本低。

为什么要划分？

当我们试图去理解事物的工作原理的时候，划分可以减轻我们的脑部压力。如果你觉得开发的越多，大脑就越能适应去处理复杂的工作，确实是这样。但是大脑的这种能力不是线性提高的，而且很快就会达到一个瓶颈。所以要处理复杂的事情，最好的办法还是在遵循单一责任原则的条件下，将它的职责划分到多个实体中去。

为什么要可测性？

对于那些对单元测试心存感激的人来说，应该不会有这方面的疑问：单元测试帮助他们测试出了新功能里面的错误，或者是帮他们找出了重构的一个复杂类里面的 bug。这意味着这些单元测试帮助这些开发者们在程序运行之前就发现了问题，这些问题如果被忽视的话很可能会提交到用户的设备上去；而修复这些问题，又至少需要一周左右的时间(AppStore 审核)。

为什么要易用

这块没什么好说的，直说一点：最好的代码是那些从未被写出来的代码。代码写的越少，问题就越少；所以开发者想少写点代码并不一定就是因为他懒。还有，当你想用一个比较聪明的方法的时候，全完不要忽略了它的维护成本。

MV(X) 的基本要素

现在我们面对架构设计模式的时候有了很多选择：

MVC

MVP

MVVM

VIPER

首先前三种模式都是把所有的实体归类到了下面三种分类中的一种：

Models(模型)— 数据层，或者负责处理数据的数据接口层。比如Person和PersonDataProvider类

Views(视图)- 展示层(GUI)。对于 iOS 来说所有以UI开头的类基本都属于这层。

Controller/Presenter/ViewModel(控制器/展示器/视图模型)- 它是Model和View之间的胶水或者说是中间人。一般来说，当用户对View有操作时它负责去修改相应Model；当Model的值发生变化时它负责去更新对应View。

将实体进行分类之后我们可以：

更好的理解

重用(主要是 View 和 Model)

对它们独立的进行测试

让我从MV(X)系列开始讲起，最后讲VIPER。

MVC - 它原来的样子

在开始讨论 Apple 的 MVC 之前，我们先来看下传统的 MVC。

在这种架构下，View 是无状态的，在 Model 变化的时候它只是简单的被 Controller 重绘；就像网页一样，点击了一个新的链接，整个网页就重新加载。尽管这种架构可以在 iOS 应用里面实现，但是由于 MVC 的三种实体被紧密耦合着，每一种实体都和其他两种有着联系，所以即便是实现了也没有什么意义。这种紧耦合还戏剧性的减少了它们被重用的可能，这恐怕不是你想要在自己的应用里面看到的。综上，传统 MVC 的例子我觉得也没有必要去写了。

传统的 MVC 已经不适合当下的 iOS 开发了。

Apple 的 MVC

理想

View 和 Model 之间是相互独立的，它们只通过 Controller 来相互联系。有点恼人的是 Controller 是重用性最差的，因为我们一般不会把冗杂的业务逻辑放在 Model 里面，那就只能放在 Controller 里了。

理论上看这么做貌似挺简单的，但是你有没有觉得有点不对劲？你甚至听过有人把 MVC 叫做重控制器模式。另外关于 ViewController 瘦身已经成为 iOS 开发者们热议的话题了。为什么 Apple 要沿用只是做了一点点改进的传统 MVC 架构呢？

现实