发出许多网络请求的 iOS 应用程序的最佳架构? [英] Best architecture for an iOS application that makes many network requests?

问题描述

我正在重新考虑我正在开发的大型应用的请求架构的方法.我目前正在使用 ASIHTTPRequest 来实际发出请求，但是由于在不同的视图控制器中采取了许多不同的操作，我需要许多不同类型的请求，因此我正在尝试找出组织这些请求的最佳系统.

I'm in the process of rethinking my approach to the request architecture of a large app I'm developing. I'm currently using ASIHTTPRequest to actually make requests, but since I need many different types of requests as a result of many different actions taken in different view controllers, I'm trying to work out the best system of organizing these requests.

我目前正在构建由应用程序委托保留的单例请求者"，并坐在那里监听表示需要发出请求的 NSNotification；他们发出请求，监听响应，并发送一个带有响应数据的新 NSNotification.这解决了我的大部分问题，但不能优雅地处理失败的请求或对同一个单例请求者的并发请求.

I'm currently building singleton "requesters" that are retained by the app delegate and sit around listening for NSNotifications that signal a request needs to be made; they make the request, listen for the response, and send out a new NSNotification with the response data. This solves most of my problems, but doesn't elegantly handle failed requests or simultaneous requests to the same singleton requester.

是否有人成功设计了一个清晰的 OO 架构以在 iOS 应用程序中发出许多不同类型的请求?

Anyone have any success devising a clear, OO architecture for making many different types of requests in an iOS app?

推荐答案

在尝试了几种方法之后，这是一个给我带来出色结果的架构，易于记录、理解、维护和扩展:

After having tried several approaches, this is one architecture that is giving me excellent results, is easy to document, understand, maintain and extend:

• 我有一个负责网络连接的对象，我们称它为网络管理器".通常这个对象是一个单例(使用 Matt Gallagher 的 Cocoa 单例宏创建).
• 由于您使用 ASIHTTPRequest(我总是这样做，很棒的 AP​​I)，我在网络管理器中添加了一个 ASINetworkQueue ivar.我让网络管理员成为该队列的代表.
• 我为我的应用所需的每种网络请求(通常为每个后端 REST 交互或 SOAP 端点)创建 ASIHTTPRequest 的子类.这还有另一个好处(详情见下文:)
• 每次我的控制器需要一些数据(刷新、viewDidAppear 等)时，网络管理器都会创建所需 ASIHTTPRequest 子类的实例，然后将其添加到队列中.
• ASINetworkQueue 负责处理带宽问题(取决于您使用的是 3G、EDGE 还是 GPRS 或 Wifi，您拥有更多带宽，并且可以处理更多请求等).这是由队列完成的，这很酷(至少，这是我理解这个队列所做的事情之一，我希望我没有弄错:).
• 每当请求完成或失败时，都会调用网络管理器(请记住，网络管理器是队列的代表).
• 网络管理员不知道如何处理每个请求的结果；因此，它只是在请求上调用一个方法！请记住，请求是 ASIHTTPRequest 的子类，因此您可以只放置管理请求结果的代码(通常，将 JSON 或 XML 反序列化为真实对象，触发其他网络连接，更新 Core Data 存储等).将代码放入每个单独的请求子类中，使用跨请求类的通用名称的多态方法，可以很容易地调试和管理恕我直言.
• 最后，我使用通知通知上面的控制器有趣的事件；使用委托协议不是一个好主意，因为在您的应用中，您通常有许多控制器与您的网络管理员通信，然后通知更加灵活(您可以让多个控制器响应相同的通知等).

• I have a single object taking care of network connectivity, let's call it a "network manager". Typically this object is a singleton (created using Matt Gallagher's Cocoa singleton macro).
• Since you use ASIHTTPRequest (which I always do, wonderful API) I add an ASINetworkQueue ivar inside my network manager. I make the network manager the delegate of that queue.
• I create subclasses of ASIHTTPRequest for each kind of network request that my app requires (typically, for each backend REST interaction or SOAP endpoint). This has another benefit (see below for details :)
• Every time one of my controllers requires some data (refresh, viewDidAppear, etc), the network manager creates an instance of the required ASIHTTPRequest subclass, and then adds it to the queue.
• The ASINetworkQueue takes care of bandwidth issues (depending on whether you are on 3G, EDGE or GPRS or Wifi, you have more bandwidth, and you can process more requests, etc). This is done by the queue, which is cool (at least, that's one of the things I understand this queue does, I hope I'm not mistaken :).
• Whenever a request finishes or fails, the network manager is called (remember, the network manager is the queue's delegate).
• The network manager doesn't know squat about what to do with the result of each request; hence, it just calls a method on the request! Remember, requests are subclasses of ASIHTTPRequest, so you can just put the code that manages the result of the request (typically, deserialization of JSON or XML into real objects, triggering other network connections, updating Core Data stores, etc). Putting the code into each separate request subclass, using a polymorphic method with a common name accross request classes, makes it very easy to debug and manage IMHO.
• Finally, I notify the controllers above about interesting events using notifications; using a delegate protocol is not a good idea, because in your app you typically have many controllers talking to your network manager, and then notifications are more flexible (you can have several controllers responding to the same notification, etc).

无论如何，这就是我一段时间以来一直这样做的方式，坦率地说，它运作良好.我可以横向扩展系统，根据需要添加更多的 ASIHTTPRequest 子类，并且网络管理器的核心保持不变.

Anyway, this is how I've been doing it for a while, and frankly it works pretty well. I can extend the system horizontally, adding more ASIHTTPRequest subclasses as I need them, and the core of the network manager stays intact.

希望对你有帮助！

这篇关于发出许多网络请求的 iOS 应用程序的最佳架构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！