最佳的建立iOS网络应用（REST客户端）的架构方法
最佳的建立iOS网络应用（REST客户端）的架构方法
关闭。这个问题是基于观点的。它目前不接受回答。
想要改进这个问题？ 可以通过事实和引用回答这个问题，编辑此帖。
改善这个问题
我是一名有经验的 iOS 开发人员，这个问题对我来说非常有趣。我看到了很多不同的资源和材料，但我仍然感到困惑。对于 iOS 网络应用程序，哪种是最好的架构？我指的是基本的抽象框架，模式，适用于每个网络应用程序，无论它是一个只有几个服务器请求的小应用程序，还是一个复杂的 REST 客户端。苹果建议使用 MVC 作为所有 iOS 应用程序的基本架构方法，但是 MVC 或者更现代的 MVVM 模式都没有解释网络逻辑代码应该放在哪里以及如何进行一般性的组织。
我需要开发类似于 MVCS（S 代表 服务）这样的东西，在这个 服务 层中放置所有 API 请求和其他网络逻辑，这个逻辑可能非常复杂？做了一些研究后，我发现了两种基本方法。在这里建议为每个网络请求创建一个单独的类到 web-service API （例如 LoginRequest 类或 PostCommentRequest 类等），这些类都继承于基本请求抽象类 AbstractBaseRequest ，并且除此之外，还要创建一些全局网络管理器，这个管理器封装了常见的网络代码和其他偏好（它可以是 AFNetworking 定制或 RestKit 固化，如果我们具有复杂的对象映射和持久性，或者甚至是使用标准 API 的自己的网络通信实现）。但是，我觉得这种方法有点过于繁琐。另一种方法是像第一种方法一样拥有一些单例的 API 调度器或管理器类，但不要为每个请求创建类，而是将每个请求封装为这个管理器类的实例公共方法，例如： fetchContacts、loginUser 方法等。那么，什么是最佳的和正确的方法？还有其他有趣的方法我还不知道吗？
我是否应该为所有这些网络内容创建另一层，例如 服务、网络提供程序 层或其他内容，而不是在我的 MVC 架构之上集成（注入）这个层，例如 Model？
我知道有很多好的方法，那么像 Facebook 客户端或 LinkedIn 客户端这样的移动端怎么处理不断增长的网络逻辑的复杂性呢？
我知道没有确切和正式的答案。 这个问题的目的是收集来自有经验的 iOS 开发人员最有趣的方法 。最佳的建议方法将被标记为被接受和奖励的声誉，其他方法将被投票。这主要是一个理论和研究问题。我希望从有经验的开发人员那里获得详细的解释，以便了解网络应用程序的基本、抽象和正确的架构方法。
抱歉，这段文本没有任何信息，无法翻译。请提供正确的文本内容。
根据这个问题的目标，我想描述我们的架构方法。
架构方法
我们的一般iOS应用程序的架构基于以下模式：服务层，MVVM，UI数据绑定，依赖注入；和函数响应式编程范式。
我们可以将典型的面向消费者的应用程序划分为以下逻辑层：
- 组装层
- 模型
- 服务
- 存储
- 管理器
- 协调者
- 用户界面
- 基础设施
组装层是我们应用程序的引导点。它包含依赖注入容器和声明应用程序对象及其依赖项。此层也可能包含应用程序的配置（url、第三方服务密钥等）。为此，我们使用Typhoon库。
模型层包含领域模型类、验证和映射。我们使用Mantle库来映射我们的模型：它支持序列化/反序列化为JSON格式和NSManagedObject模型。对于我们的模型的验证和表单表示，我们使用FXForms和FXModelValidation库。
服务层声明了我们用于与外部系统交互的服务，以发送或接收在我们的领域模型中表示的数据。因此，通常我们有用于与服务器API（每个实体）、消息传递服务（如PubNub）、存储服务（如Amazon S3）等通信的服务。基本上，服务包装由SDK提供的对象（例如PubNub SDK）或实现自己的通信逻辑。对于通用网络，我们使用AFNetworking库。
存储层的目的是在设备上组织本地数据存储。我们使用Core Data或Realm进行此操作（两者都有优缺点，决定使用什么是基于具体规格的）。对于Core Data设置，我们使用MDMCoreData库和一堆类 - 存储 - （类似于服务），这些类为每个实体提供访问本地存储的API。对于Realm，我们只需使用类似的存储来访问本地存储。
管理层是我们的抽象层和封装层所在的地方。
在管理职能中，可能包括：
- 凭证管理器及其不同的实现方式（钥匙串、NSDefaults等）
- 当前会话管理器，它知道如何保持和提供当前用户的会话
- 捕获管道，提供对媒体设备的访问（视频录制、音频、拍照等）
- BLE管理器，提供对蓝牙服务和外围设备的访问
- 地理位置管理器
- ……
因此，在管理者的角色中，可以有任何实现特定方面或应用程序工作所需关注的逻辑的对象。
我们尽量避免单例模式，但如果需要，这个层是它们需要存放的地方。
协调员层提供依赖于其他层（服务、存储、模型）的对象，以将它们的逻辑结合成一系列工作序列，以满足特定模块（功能、屏幕、用户故事或用户体验）的需求。通常它链式地执行异步操作，并知道如何对它们的成功和失败作出反应。例如，您可以想象一个消息功能的MessagingCoordinator对象。处理发送消息操作可能是这样的：
- 验证消息（模型层）
- 本地保存消息（消息存储）
- 上传消息附件（Amazon S3服务）
- 更新消息状态和附件url，以及本地保存消息（消息存储）
- 将消息序列化为JSON格式（模型层）
- 发布消息到PubNub（PubNub服务）
- 更新消息状态和属性并在本地保存它（消息存储）
在上述每个步骤中都会相应地处理错误。
UI层由以下子层组成：
- ViewModels
- ViewControllers
- Views
为了避免大量视图控制器，我们采用MVVM模式，并在ViewModels中实现UI演示所需的逻辑。 ViewModel通常依赖于协调员和管理器。 ViewModel由ViewControllers和某些类型的视图（例如表格视图单元格）使用。 ViewControllers和ViewModels之间的粘合剂是数据绑定和命令模式。为了使它们粘合，我们使用ReactiveCocoa库。
我们还使用ReactiveCocoa和其RACSignal概念作为所有协调员、服务、存储方法的接口和返回值类型。这使我们能够链式操作、并行或串行运行它们，以及ReactiveCocoa提供的许多其他有用的功能。
我们尝试以声明性方式实现我们的UI行为。数据绑定和自动布局对实现这一目标非常有帮助。
基础设施层包含所有应用程序工作所需的帮助器、扩展和工具。
这种方法对我们以及我们通常构建的应用程序非常有效。但是您应该理解，这只是一种主观的方法，应该针对具体的团队目的进行调整/更改。
希望这可以帮助您！
此外，您还可以在iOS Development as a Service博客文章中找到有关iOS开发过程的更多信息。