MVC是iOS开发里面我们一开始接触得最多的架构了，也是开发中常用的架构之一。虽然有MVP、MVVM、VIPER这些架构，但在深入了解这些之前，我们是否真的把MVC用对了吗？在日常使用MVC开发的时候，View和Controller耦合会很严重， 像viewDidLoad、viewWillAppear这些view的生命周期都会在controller里面来管理。再加上controller还负责了代理、数据源、网络请求等，于是controller就变得越来越庞大，越来越混乱，很不好测试。久而久之，这个controller就没人敢再去碰了。
MVC 本身的概念相当简单，同时它也给了我们很大的自由度。往往我们利用这个自由度，“随意”将逻辑放在controller层中，也就写成了上面说的很乱的Controller。在日常开发中，MVC在较小的项目中带来了方便快捷，但随着项目逐渐变大，需求越来越多的时候，逻辑越来越多，controller层越来越大， 久而久之代码就越来越乱。我看过不少文章中很多都讲了MVC的缺陷和不足，讲了controller过于复杂，不好维护。MVVM，MVP等架构的出现，都是为了减轻Controller的负担，最重要的是要清晰的将逻辑表达出来。正如喵神博客中所说的：“‘广义’的MVC (比如 MVVM 或者 VIPER)，又或者更激进一点，转换思路使用 Reactive 模式或 Reducer 模式，其实所想要解决的问题本质在于，我们要如何才能更清晰地管理“用户操作，模型变更，UI 反馈”这一数据流动的方式。”但在使用传统MVC的实际开发中，如果不严格遵守 MVC 的思想我们很容易写出View和模型Model直接通信的代码。
那我们有什么方法可以避免这种情况呢？
喵神的博客关于 MVC 的一个常见的误用循序渐进讲了很清楚了，我这里就试着讲讲大神的Swift代码实现。
Model层：
- 所有有关模型数据的方法都应该包含在里面，获取本地数据或者获取网络数据的实现都应该在这里面。减轻Controller的负担。
- 如果这个模型是一直存在的，并且只有一个，我们可以直接写一个单例，也不需要Controller持有这个Model。
- 在模型中使用内嵌枚举来表示模型的变化。这样可以增加代码可读性，使逻辑变得更清晰。
- 利用Swift中的值语义和属性观察器来监听出模型的变化并转换成内部所定义的枚举。
- 将消息通过通知中心发出，将模型的变化告诉控制器，再通过控制器去修改视图，体现出理想化数据流动。
View层：
- 不接触模型，等用户操作，或者等Controller来控制显示。
Controller层：
- 监听模型的变化通知，根据通知中心的信息去获取Model的变化，根据逻辑去修改View。
- 利用枚举的语义，将有关同一个模型变化的操作都写在一起。
- 视图变化的时候，不直接既修改模型又修改视图。
- 视图变化的时候，只调用模型的方法来修改模型。等待模型通过通知中心发出的消息，再根据消息，统一在一个地方修改视图。
使用这种写法，的确可以清晰地看到那个理想化的单向数据流动
UI 操作 -> 经由 View Controller 进行模型更新 -> 新的模型经由 View Controller 更新 UI -> 等待新的 UI 操作
mvc.png
传统的MVC架构可能不能满足当前的开发需求，但如果是小项目而且看中开发效率，MVC仍然是一个很不错的选择。架构也没什么好与坏，最重要是我们要选择一个合适的。
网友评论