2

リクエスト/レスポンスにSOAPとXMLを使用するWebサービスクライアントをiOSに実装したいと思います。私のビューは、最初のbusinnesロジックを開始します(ユーザーがボタンなどを押して、method_Aと呼ばれるbusinnesメソッドを開始します)。

したがって、method_Aを持つクラスがあり、このメソッドはユーザーがログインしているかどうかを確認し、SOAPConnectorクラスを介して非同期でリクエストを開始します。したがって、UIはブロックされません(非同期)。SOAPConnectorクラスはXMLを受け取り、要求を処理します。したがって、sendSynchronousRequestでNSURLRequestとNSURLConnectionを使用します。

応答は、応答を受け取るResponseクラスに送り返されます。次に、このクラスは応答XMLを解析します。したがって、NSXMLParserを使用してxmlを解析するXMLManagerという追加のクラスを使用します。しかし、ここでも、解析されたxmlを取得するデリゲートが必要です。また、解析後、リクエストを開始した最初のクラスに解析済みのxmlを返すための追加のメソッドを実装する必要があります。

これが正しい方法かどうか本当に疑問に思っています。最初の問題は、UIをブロックしないようにする非同期要求(最初のコールバック)です。2番目の問題は、デリゲートを使用するように強制される解析です(2番目のコールバック)。これにより、多くのクラスとメソッドが生成され、これが正しい方法であるとは思えません。クラスの唯一の目的は、デリゲートと非同期の問題を管理することです。だから私は何か提案を求めており、これを解決する方法を助けています。この問題を解決するための優れたデザインパターンをいくつか知っていますか?

4

1 に答える 1

0

選択した設計パターンを説明する方法にいくつかの矛盾があることを除けば、次のとおりです。

次に、リクエストを非同期で開始します

対。

したがって、sendSynchronousRequest で NSURLRequest と NSURLConnection を使用します。


とはいえ、あなたのアプローチは健全に思えます。特定した問題に対処する:

したがって、sendSynchronousRequest で NSURLRequest と NSURLConnection を使用します。

それが非同期APIを使う目的ではないでしょうか。NSURLConnection実際に非同期で動作している場合は、その問題をカバーする必要があります。

2番目の問題は、デリゲートの使用を余儀なくされている解析です

このアプローチにより、より多くのクラス、委譲などが発生しますが、テストに関してはベスト プラクティスに準拠しています。単体テストやその他のテスト戦略を実行している場合 (そうではありませんか?)、このプロセスを機能的に分解しない限り、分離してテストすることはさらに困難です。

Test-Drive iOS Developmentという本にアクセスできる場合は、テスト容易性を考慮して Web サービスを使用するためのベスト プラクティスに関する優れたセクションがあります。

于 2012-10-05T11:31:22.910 に答える