iOS体系结构：MVVM-C，服务（6/6）

服务层是已经存在了数十年的设计模式。它基于这样一个概念，即系统应分为不同的层（例如洋葱），每个层的每个层都有不同的职责。服务层应该是与外界的连接，无论是数据库，远程服务器，蓝牙连接等。

在该服务层中，应该有多个服务，并且每个服务都应承担处理特定种类的服务或资源的单一责任。

基本上就是这样，它实际上是一个简单的概念，我们可能已经在我们的应用程序中以某种方式使用了它。例如，我们通常有一个ApiClient类，该类处理服务器上的REST API。但是我想指出的是，这与我们在整个系列中一直在构建的体系结构非常吻合的原因在于，我们应该组织和构造该层以充分利用它。

让我们继续研究ApiClient示例。我们所有人都可能已经熟悉ApiClient的概念。我们基于Apple的URLSession或其他框架构建一个负责发出HTTP请求的对象。但这应该是它的唯一责任。它应该不了解我们的模型和业务逻辑。

因此，如果所有这些业务逻辑都不能在ApiClient中，并且最肯定也不应在我们较低的ViewModel / View层中，应该去哪里？这就是服务层的所在。

服务通常会包裹某种客户端（在本例中为ApiClient），并在其之上添加所有模型解析和业务逻辑。我们可能很想创建一个ApiService来处理我们应用程序中的所有API需求，并且在一个非常简单的应用程序中它可能会起作用。

但是，我建议我们按逻辑单元来分隔服务（即使它们与本示例中的同类）相同。例如，您可能具有一个用于处理登录/注册的SessionService和一个用于将图片张贴到服务器的PostService 。

这样，当向ViewModel注入服务时，它需要的是获取仅处理应用程序特定部分需求的特定服务。同样， SRP 。

这是一个非常简单的服务的缩写示例。让我们在API上搜索位置的PlaceService 。

我们从一个概述操作的协议开始，我们将在此服务上调用该操作。在这里拥有一个协议确实很有用，因为我们可能想要切换执行相同操作但使用不同来源（例如不同的API或缓存）的实现。或者，与以往一样，它使测试变得更加容易。