PROSAGA码农传奇-网络/光纤-用于构建iOS网络应用程序（REST客户端）的最佳架构方法

I want to understand basic, abstract and correct architectural approach for networking applications in iOS：没有用于构建应用程序体系结构的“最佳”或“最正确”方法。这是一项非常有创意的工作。您应该始终选择最直接和可扩展的体系结构，这对于任何开始从事您的项目的开发人员或团队中的其他开发人员都是显而易见的，但是我同意，可能存在“好”和“坏”的情况。 ”架构。

您说：collect the most interesting approaches from experienced iOS developers，我认为我的方法不是最有趣或最正确的，但是我已经在多个项目中使用了它，并对它感到满意。它是您上面提到的方法的一种混合方法，并且根据我自己的研究工作得到了改进。我对构建方法的问题很感兴趣，该方法结合了几种众所周知的模式和习惯用法。我认为许多Fowler的企业模式都可以成功地应用于移动应用程序。以下是最有趣的列表，我们可以将其用于创建iOS应用程序架构（我认为）：服务层，工作单元，远程外观，数据传输对象，网关，层超类型，特例，域模型。您应该始终正确设计模型层，并且永远不要忘记持久性（它可以显着提高应用程序的性能）。您可以Core Data为此使用。但是您不要忘记，这Core Data不是ORM或数据库，而是具有持久性的对象图管理器是不错的选择。因此，通常Core Data情况下，对于您的需求而言可能过于繁琐，您可以查看诸如Realm和Couchbase Lite之类的新解决方案，或者基于原始SQLite或LevelDB构建自己的轻量级对象映射/持久层。。另外，我建议您熟悉域驱动设计和CQRS。

首先，我认为，我们应该创建另一个网络层，因为我们不希望使用胖控制器或笨拙，不堪重负的模型。我不相信那些fat model, skinny controller东西。但我相信在skinny everything方法，因为不用上课应该是脂肪，永远。通常可以将所有网络抽象为业务逻辑，因此，我们应该在其中放置另一层。服务层是我们需要的：

It encapsulates the application's business logic,  controlling transactions 
and coordinating responses in the implementation of its operations.
在我们的MVC领域Service Layer中，就像域模型和控制器之间的中介一样。此方法有一个非常类似的变体，称为MVCS，其中a Store实际上是我们的Service层。Store出售模型实例并处理网络，缓存等。我想提一提，您不应该在服务层中编写所有网络和业务逻辑。这也可以认为是不良设计。有关更多信息，请查看Anemic和Rich域模型。可以在模型中处理某些服务方法和业务逻辑，因此它将是一个“丰富”（具有行为）模型。

我总是广泛使用两个库：AFNetworking 2.0和ReactiveCocoa。我认为这是与网络和Web服务交互或包含复杂UI逻辑的任何现代应用程序所必需的。

建筑
首先，我创建一个通用APIClient类，它是AFHTTPSessionManager的子类。这是应用程序中所有网络的主力军：所有服务类都将实际的REST请求委托给它。它包含HTTP客户端的所有自定义设置，我在特定应用程序中需要这些自定义设置：SSL固定，错误处理以及创建NSError具有详细失败原因以及所有API错误和连接错误的描述的简单对象（在这种情况下，控制器将能够显示有关以下内容的正确消息）用户），设置请求和响应序列化程序，http标头和其他与网络相关的内容。然后，我在逻辑上将所有的API请求转换的子服务，或者更确切地说，是微服务：UserSerivces，CommonServices，SecurityServices，FriendsServices依其实现的业务逻辑等。这些微服务中的每一个都是一个单独的类。它们一起形成一个Service Layer。这些类包含用于每个API请求的方法，过程域模型，并且始终将RACSignal带有已解析的响应模型或的NSError返回给调用方。

我想提到的是，如果您具有复杂的模型序列化逻辑，请为其创建另一个层：类似于Data Mapper，但更通用，例如JSON / XML-> Model mapper。如果您有缓存：那么也将其创建为单独的层/服务（您不应将业务逻辑与缓存混在一起）。为什么？因为正确的缓存层具有其自身的陷阱可能会非常复杂。人们实施复杂的逻辑以获取有效的，可预测的缓存，例如具有基于profunctor的投影的单面缓存。您可以阅读有关这个名为Carlos的美丽图书馆的信息，以了解更多信息。并且不要忘记，Core Data确实可以帮助您解决所有缓存问题，并减少编写逻辑。另外，如果您NSManagedObjectContext和服务器请求模型之间有某种逻辑，则可以使用存储库模式，该模式将检索数据并将其映射到实体模型的逻辑与作用在模型上的业务逻辑分开。因此，即使您具有基于Core Data的体系结构，我也建议您使用Repository模式。仓库可以抽象的东西，比如NSFetchRequest，NSEntityDescription，NSPredicate等为普通方法，如get或put。

在Service层中完成所有这些操作之后，调用者（视图控制器）可以使用响应来执行一些复杂的异步处理：借助ReactiveCocoa原语，进行信号操作，链接，映射等操作，或者仅订阅它并在视图中显示结果。我注入与依赖注入在所有这些服务类我APIClient，这将转化特定服务调用成相应的GET，POST，PUT，DELETE，等请求REST端点。在这种情况下APIClient，将隐式传递给所有控制器，您可以通过对APIClient服务类进行参数化来使其显式。如果您想使用不同的自定义设置，这可能很有意义APIClient对于特定的服务类，但是如果出于某些原因，您不想要多余的副本，或者您可以确定始终使用一个特定的实例（无自定义），请将APIClient其设为单例，但不要，请不要'不要将服务类作为单例。

然后，每个带有DI的视图控制器再次注入所需的服务类，调用适当的服务方法，并将其结果与UI逻辑组合在一起。对于依赖注入，我喜欢使用BloodMagic或更强大的Typhoon框架。我从不使用单例，神职人员APIManagerWhatever或其他错误的东西。因为如果你打电话给班级WhateverManager，这表明你并不知道班级的目的，这是一个错误的设计选择。Singletons也是一种反模式，在大多数情况下（罕见情况除外）是错误的解决方案。仅当满足以下所有三个条件时，才应考虑单例：

无法合理分配单个实例的所有权；
延迟初始化是可取的。
否则不提供全局访问。
在我们的案例中，单个实例的所有权不是问题，并且在将God Manager划分为服务之后，我们也不需要全局访问，因为现在只有一个或几个专用控制器需要特定的服务（例如，UserProfile控制器需求UserServices等）。 。

我们应该始终S遵循SOLID中的原则，并使用关注点分离，因此不要将所有服务方法和网络调用归为一类，因为这很疯狂，尤其是在开发大型企业应用程序时。这就是为什么我们应该考虑依赖注入和服务方法。我认为这种方法是现代且面向对象的。在这种情况下，我们将应用程序分为两部分：控制逻辑（控制器和事件）和参数。

一种参数是普通的“数据”参数。那就是我们传递函数，操纵，修改，持久化等等的东西。这些是实体，集合，集合，案例类。另一种是“服务”参数。这些是封装业务逻辑，允许与外部系统进行通信，提供数据访问的类。

这是我的体系结构的一般工作流程示例。假设我们有一个FriendsViewController显示用户好友列表的，并且有一个选项可以从好友中删除。我在我的FriendsServices课程中创建了一个方法：

- (RACSignal *)removeFriend:(Friend * const)friend
Friend模型/领域对象在哪里（User如果它们具有相似的属性，则可以只是一个对象）。引擎盖下此方法分析Friend，以NSDictionaryJSON的参数friend_id，name，surname，friend_request_id等等。我总是将Mantle库用于此类样板和模型层（前后解析，在JSON中管理嵌套的对象层次结构等）。解析后它调用APIClient DELETE方法以使实际的REST请求并返回Response在RACSignal给调用者（FriendsViewController在我们的例子），以供用户或任何显示适当的消息。

如果我们的应用程序很大，则我们必须将逻辑更清楚地分开。例如，将逻辑与一个逻辑混合或建模并不总是一件好事。当我描述我的方法时，我曾说过该方法应该在层中，但是如果我们要花很多精力，我们会注意到它更好地属于。让我们记住什么是存储库。埃里克·埃文斯（Eric Evans）在他的书[DDD]中给出了准确的描述：RepositoryServiceremoveFriendServiceRepository

存储库将某种类型的所有对象表示为概念集。除了具有更复杂的查询功能外，它的作用类似于集合。

因此，a Repository本质上是一个使用Collection样式语义（添加，更新，删除）提供对数据/对象的访问的外观。这就是为什么当你碰到这样的：getFriendsList，getUserGroups，removeFriend你可以将其放置在Repository，因为集合类语义是相当清楚的在这里。和类似的代码：

- (RACSignal *)approveFriendRequest:(FriendRequest * const)request;
绝对是一种业务逻辑，因为它超出了基本CRUD操作，并且连接了两个域对象（Friend和Request），这就是为什么应将其放在Service层中。我还要注意：不要创建不必要的抽象。明智地使用所有这些方法。因为如果您要用抽象来淹没您的应用程序，这将增加其偶然的复杂性，并且复杂性会在软件系统中 引起更多的问题

我为您描述了一个“旧的” Objective-C示例，但是这种方法可以很容易地应用于Swift语言，并进行了许多改进，因为它具有更多有用的功能和功能。我强烈建议使用以下库：Moya。它使您可以创建更优雅的APIClient图层（您记得的是我们的主力军）。现在，我们的APIClient提供程序将是一个值类型（枚举），其扩展名符合协议并利用解构模式匹配。Swift枚举+模式匹配使我们能够像经典函数式编程一样创建代数数据类型。我们的微服务将APIClient像通常的Objective-C方法一样使用此改进的提供程序。对于模型层，Mantle可以使用ObjectMapper库代替或者我喜欢使用更优雅，更实用的Argo库。

因此，我描述了我的一般体系结构方法，我认为该方法可以适用于任何应用程序。当然，还有很多改进。我建议您学习函数式编程，因为您可以从中受益匪浅，但也不要太过分。消除过多的，共享的，全局可变的状态，创建不可变的域模型或创建没有外部副作用的纯函数通常是一种好习惯，并且新Swift语言鼓励这样做。但请始终记住，使用繁重的纯功能模式，基于类理论的方法来重载代码是一个坏主意，因为其他开发人员将阅读并支持您的代码，并且他们可能对此感到沮丧或恐惧。prismatic profunctors以及不可变模型中的这类内容。与ReactiveCocoa：的相同之处：不要过多地RACify编写代码，因为它可能很快变得不可读，尤其是对于新手。当它可以真正简化您的目标和逻辑时使用它。

因此，read a lot, mix, experiment, and try to pick up the best from different architectural approaches。这是我能给您的最佳建议。