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

问题描述

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

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

有人成功地设计了一个清晰的面向对象架构来在 iOS 应用中发出许多不同类型的请求吗?

解决方案

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

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

无论如何，这就是我已经这样做了一段时间的方式，坦率地说，它运作得很好.我可以横向扩展系统，根据需要添加更多 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.

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.

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:

• 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).

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.

Hope it helps!

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