私は2種類のデータを持っていますが、いくつかは永続化する必要があり、そうでないものもあります。iPhone - viewControllerとネットワークリクエストのアーキテクチャ
私はすべてのネットワーク関連のコードをどこに置くか、私のUIViewController内で、すべてのネットワーク要求がどこから始まるのか、別のレイヤーを考えています。私が念頭に置いていた何
はこれです：
はNetworkManagerと呼ばれる層を持っています。 NetworkManagerは私のすべてのWebサービスコールにシンガートンです。
ネットワーク管理者にリクエストを発行し、ローカルコアデータDBにレスポンスを保存させ、UIViewControllerにFetchResultsControllerを使用してデータを聞かせてください。
しかし、他にも多くの種類のリクエストがあります。たとえば：ログイン要求、ユーザー情報要求、friendsNearByなど...一部はデータベースに永続性を持たせる必要はなく、FRCアーキテクチャに適合しないものもあります。リクエストのこれらのタイプの場合
は、私の知る限り見るように、それを処理する2つの方法があります。
1.はViewControllersとNetworkManagerの間で分離し、別の層を有します。 Mediatorとしましょう。 Mediatorは、networkManagerから辞書（JSON）リクエストを取得し、アプリケーションロジックに従ってそれ以外のことが必要な場合は、適切な名前とデータで通知を送信します。メディエータが要求を発行したUIViewControllerを保存する場合、通知を送信するのではなく、直接応答を委任することができます。
の流れは次のようになります：
MyUiViewController - > Mediator -> NetworkManger->Mediator-> PostNotification (or directly back to MyUiViewController)
Pros:
Decoupling
Nice structure and separation of concerns
Cons:
Harder to code
Sometimes harder to understand and debug.
2.ブロックとのネットワーク要求を発行し、この3階層アーキテクチャを有するが、代わりにMyUiViewControllersを持っていません。 MediatorがMyUiViewControllerの前に応答を傍受するのではなく、MyUiViewControllerがブロックを使用してレスポンスを処理するようにします。
Pros:
Simple and quick to code
Easy to understand
Cons:
Coupling of network code inside your controllers
私は人々の経験から最善のものについての提案やコメントを得ることを望ん、またはこれを行うの他の/より良い方法ました。