iOS项目开发MVVM架构实践（第一篇：Router协议）

Posted 2023-04-24

参考技术A 项目的开始我们必然要面临一些准备工作来做统筹布局（如： 网络API的封装、数据处理与UI布局的选择等等），我们这边选择的是Alamofire、ObjectMapper、AlamofireObjectMapper、ReactiveCocoa作为MVVM分层架构的现实：

1）运用ObjectMapper达到数据之间的相互转化；

2）结合Alamofire、ObjectMapper、AlamofireObjectMapper与ReactiveCocoa封装网络接口让数据可传递、可监听，为调用API接口服务。

3）通过viewmodel的属性（Property）和动作(Action)给view层提供必要的数据和执行的动作。

上面大致介绍了整个架构的现实原理，接下来我们要介绍的网络接口封装的第一步Router协议的实现。Router协议作为网络层现实的一部分，目的就是把API地址转化为更加容易理解的Router名称供其他地方使用，如：

这就是一个登录API的现实，RouterConvertible 就是我们所要现实的router协议，我们要让router协议具备网络请求的必要属性，实现如下:

从实际上考虑除了urlPath需要外部提供，headers和paramters是可选的，method和parameterEncoding可以给与默认值，在需要的时候在作调整，那么如何让这个协议现实这样的功能呢？

swift为我们提供了协议扩展，让我们轻松现实这样的功能，如下：

综上所述，我们的Router协议的实现已大功告成！

iOS 架构模式--解密 MVC，MVP，MVVM以及VIPER架构

• 本文由译者lynulzy（）翻译

• 原文：

---

在 iOS 中使用 MVC 架构感觉很奇怪？ 迁移到MVVM架构又怀有疑虑？听说过 VIPER 又不确定是否真的值得切换？

相信你会找到以上问题的答案，如果没找到请在评论中指出。

你将要整理出你在 iOS 环境下所有关于架构模式的知识。我们将带领大家简要的回顾一些流行的架构，并且在理论和实践上对它们进行比较，通过一些小的例子深化你的认知。如果对文中提到的一些关键词有兴趣，可以点击连接去查看更详细的内容。

掌控设计模式可能会使人上瘾，所以要当心，你可能会对一些问题清晰明了，不再像阅读之前那样迷惑，比如下面这些问题：

谁应该来负责网络请求？Model 还是 Controller ？

应该怎样向一个新的页面的 ViewModel 传入一个 Model ?

谁来创建一个 VIPER 模块，是 Router 还是 Presenter ?

为什么要关注架构设计？

因为假如你不关心架构，那么总有一天，需要在同一个庞大的类中调试若干复杂的事情，你会发现在这样的条件下，根本不可能在这个类中快速的找到以及有效的修改任何bug.当然，把这样的一个类想象为一个整体是困难的，因此，有可能一些重要的细节总会在这个过程中会被忽略。如果现在的你正是处于这样一个开发环境中，很有可能具体的情况就像下面这样：

• 这个类是一个UIViewController的子类

• 数据直接在UIViewController中存储

• UIView类几乎不做任何事情

• Model 仅仅是一个数据结构

• 单元测试覆盖不了任何用例

以上这些情况仍旧会出现，即使是你遵循了Apple的指导原则并且实现了其 (模式，所以，大可不必惊慌。Apple所提出的 模式存在一些问题，我们之后会详述。

在此，我们可以定义一个好的架构应该具备的特点：

1. 任务均衡分摊给具有清晰角色的实体

2. 可测试性通常都来自与上一条（对于一个合适的架构是非常容易）

3. 易用性和低成本维护

为什么采用分布式?

采用分布式可以在我们要弄清楚一些事情的原理时保持一个均衡的负载。如果你认为你的开发工作越多，你的大脑越能习惯复杂的思维，其实这是对的。但是，不能忽略的一个事实是，这种思维能力并不是线性增长的，而且也并不能很快的到达峰值。所以，能够战胜这种复杂性的最简单的方法就是在遵循 的前提下，将功能划分给不同的实体。

为什么需要易测性？

其实这条要求对于哪些习惯了单元测试的人并不是一个问题，因为在添加了新的特性或者要增加一些类的复杂性之后通常会失效。这就意味着，测试可以避免开发者在运行时才发现问题----当应用到达用户的设备，每一次维护都需要浪费长达至少[一周](http://appreviewtimes.com)的时间才能再次分发给用户。

为什么需要易用性？

这个问题没有固定的答案，但值得一提的是，最好的代码是那些从未写过的代码。因此，代码写的越少，Bug就越少。这意味着希望写更少的代码不应该被单纯的解释为开发者的懒惰，而且也不应该因为偏爱更聪明的解决方案而忽视了它的维护开销。

MV(X）系列概要

当今我们已经有很架构设计模式方面的选择:

前三种设计模式都把一个应用中的实体分为以下三类：

• Models--负责主要的数据或者操作数据的，可以想象 Perspn 和 PersonDataProvider 类。

• Views--负责展示层（GUI），对于iOS环境可以联想一下以 UI 开头的所有类。

• Controller/Presenter/ViewModel--负责协调 Model 和 View，通常根据用户在View上的动作在Model上作出对应的更改，同时将更改的信息返回到View上。

将实体进行划分给我们带来了以下好处：

• 更好的理解它们之间的关系

• 复用（尤其是对于View和Model）

• 独立的测试

让我们开始了解MV(X)系列，之后再返回到VIPER模式。

MVC的过去

在我们探讨Apple的MVC模式之前，我们来看下。

传统的MVC

在这里，View并没有任何界限，仅仅是简单的在Controller中呈现出Model的变化。想象一下，就像网页一样，在点击了跳转到某个其他页面的连接之后就会完全的重新加载页面。尽管在iOS平台上实现这这种MVC模式是没有任何难度的，但是它并不会为我们解决架构问题带来任何裨益。因为它本身也是，三个实体间相互都有通信，而且是紧密耦合的。这很显然会大大降低了三者的复用性，而这正是我们不愿意看到的。鉴于此我们不再给出例子。

“传统的MVC架构不适用于当下的iOS开发”

苹果推荐的MVC--愿景

Cocoa MVC

由于Controller是一个介于View 和 Model之间的协调器，所以View和Model之间没有任何直接的联系。Controller是一个最小可重用单元，这对我们来说是一个好消息，因为我们总要找一个地方来写逻辑复杂度较高的代码，而这些代码又不适合放在Model中。

理论上来讲，这种模式看起来非常直观，但你有没有感到哪里有一丝诡异？你甚至听说过，有人将MVC的缩写展开成（Massive View Controller），更有甚者，也成为iOS开发者面临的一个重要话题。如果苹果继承并且对MVC模式有一些进展，所有这些为什么还会发生？

苹果推荐的MVC--事实

Realistic Cocoa MVC

Cocoa的MVC模式驱使人们写出臃肿的视图控制器，因为它们经常被混杂到View的生命周期中，因此很难说View和ViewController是分离的。尽管仍可以将业务逻辑和数据转换到Model，但是大多数情况下当需要为View减负的时候我们却无能为力了，View的最大的任务就是向Controller传递用户动作事件。ViewController不再承担一切代理和数据源的职责，通常只负责一些分发和取消网络请求以及一些其他的任务，因此它的名字的由来...你懂的。

你可能会看见过很多次这样的代码：

var userCell = tableView.dequeueReusableCellWithIdentifier( "identifier" ) as UserCell

以上是关于iOS项目开发MVVM架构实践（第一篇：Router协议）的主要内容，如果未能解决你的问题，请参考以下文章

UWP开发之Mvvmlight实践九：基于MVVM的项目架构分享

iOS 架构模式--解密 MVC，MVP，MVVM以及VIPER架构

iOS架构模式--解密 MVC，MVP，MVVM以及VIPER架构

MVVM With ReactiveCocoa

软件架构实践读后感第一篇

MVVM With ReactiveCocoa