iOS开发学习笔记：对MVC、MVVM建立认识

本文参考:

iOS 架构模式 - 简述 MVC, MVP, MVVM 和 VIPER (译)

浅谈 MVC、MVP 和 MVVM 架构模式

在整个 GUI 编程领域，MVC 已经有将近50年的历史，并且产生了很多变种，例如 MVA、MVP、MVVM 等等。其实 MVC 并没有一个明确的定义，网上也流传着各种各样的 MVC 架构图。

MVC本身的框架思想非常的优秀，当出现问题时首先要考虑的并不是去替换掉现有的框架而是从设计的角度去优化现有的代码以及逻辑，让整个系统达到一个最优的组合。

学习iOS开发不久，就开始接触MVC这个最出名并且应用最广泛的架构模式。也开始逐渐去了解其他架构模式。

MVC、MVP、MVVM模式都是把所有的实体归类到了下面三种分类中的一种：

• Models - 负责持有数据，进行数据处理的数据访问层。设想一下Person，PersonDataProvider类。

• Views - 负责数据展现层（Graphical User Interface），在iOS端可认为所有以UI前缀的类。

• Controller/Presenter/ViewModel - 负责协调处理Models和Views之间的交互。

我们先从几种不同的MVC开始吧

ASP.NET MVC：

在微软的ASP.NET MVC Overview一文中，描述了 MVC 模式，在此引用文章的描述示意图：

image

基于此图我简单的理解为：

View展示Model中的内容；Controller管理View和Model。

Spring MVC:

与 ASP.NET 不同，Spring MVC 对于 MVC 架构模式的实现就更加复杂了，增加了一个用于分发请求、管理视图的 DispatchServlet：

image

Model、View 和 Controller 之间的关系可以理解为：

通过 DispatchServlet 将控制器层和视图层完全解耦；
视图层和模型层之间没有直接关系，只有间接关系，通过控制器对模型进行查询、返回给 DispatchServlet 后再传递至视图层；

Cocoa MVC：

理想状态的Cocoa MVC不做详细说明，实际上的Realistic Cocoa MVC其实甚至被人称为重控制器模式。虽然 View 和 View Controller 是技术上不同的组件，但它们几乎总是手牵手在一起，成对的。我们正规化它的示意图：

image

其实我实际上编写的代码，的确许多逻辑被放在了View Controller里。

如果对于你的小项目，不打算投入很多时间去设计架构，也不打算投入太多成本去维护，那么Cocoa MVC是你要选择的模式。

在开发速度上，Cocoa MVC是最好的架构模式。

而MVVM：

在典型的 MVC 应用里，许多逻辑被放在 View Controller 里。它们中的一些确实属于 View Controller，但更多的是所谓的“表示逻辑（presentation logic）”，以 MVVM 属术语来说，就是那些将 Model 数据转换为 View 可以呈现的东西的事情，例如将一个 NSDate 转换为一个格式化过的 NSString。

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

image

• MVVM 架构把 ViewController 看做 View。
• View 和 Model 之间没有紧耦合

MVVM其实就是一个 MVC 的增强版，我们正式连接了视图和控制器，并将表示逻辑从 Controller 移出放到一个新的对象里，即 View Model。MVVM 听起来很复杂，但它本质上就是一个精心优化的 MVC 架构。

其具体的使用还待实践后的补充～

结尾对几种架构的优点进行总结

一个好的架构应有的特征：

1. 严格划分，均衡分配实体间的角色和职责
2. 可测性强
3. 便于使用，且维护成本低

• Cocoa MVC：

• 划分 - View和Model确实是分离了，但是View和Controller还是紧紧地耦合在一起。

• 可测试性 - 由于划分的不好，你可能只能测试你的Model。

• 易用性 - 相比于其他模式代码量最小，此外门槛低，每个人都能熟练掌握，即使不是一个非常有经验的开发者也能进行维护。

关于这几点本人深有同感，特别是第三点，这也是前辈们教我上手提高效率的体现。再加上上文说的开发速度、不用过多时间去设计架构的优点，Cocoa MVC成为了外包公司的主要选择之一。

• MVVM:

• 划分 - MVVM 框架里面的 View 比 MVP 里面负责的事情要更多一些。因为前者是通过 ViewModel 的数据绑定来更新自身状态的，而后者只是把所有的事件统统交给 Presenter 去处理就完了，自己本身并不负责更新。

• 可测性 - 因为 ViewModel 对 View 是一无所知的，这样我们对它的测试就变得很简单。View 应该也是能够被测试的，但是可能因为它对 UIKit 的依赖，你会直接略过它。

• 易用 - 在实际的应用当中 MVVM 会更简洁一些。而在 MVVM 下，你只需要用绑定就可以解决更新 View 的状态。

笔记内容略粗糙，其实和本人理解不深有很大关系，更准确，更深的内容仍需不停学习以及实践！