私は、基本的にサーバー側の REST API のクライアントであるアプリに取り組んでいます。
このアプリはサーバー データに大きく依存しています (Facebook のようなものです)。
私のアプリには、サーバーとのすべての対話を管理する ServerAPI クラスがあります。これは基本的に、「Model-View-Controller-Store」パターンの「Store」として機能します。アプリの残りの部分は、このクラスのシングルトン インスタンスを使用してデータにアクセスします。
たとえば、View Controller の 1 つが Articles のリストを必要とする場合、次のように呼び出します。
[[ServerAPI sharedAPI] fetchArticlesWithCompletion:^(NSArray *articles){
// Do something with the new articles.
}];
このようにして、アプリは記事がどのように取得されるかを気にしません。サーバーからではなく、ローカル ファイルからフェッチされたことがわかっています。
これはすべて問題ありません。
今の問題は、ある種のキャッシングを追加したいということです。いろいろ調べてみると、Core Data がこの仕事に最適なツールのように思えます (しかし、私は間違いなく他の提案にもオープンです)。
有望に見える AFIncrementalStore (AFNetworking の NSIncrementalStore サブクラス) を見つけました。しかし、NSIncrementalStore に関する私の (現在は限定的な) 理解から、アプリ (ビュー コントローラー) は依然として NSFetchRequests および MOC と直接対話してデータをフェッチします。
現在の API (ServerAPI シングルトン) を維持し、コア データを「舞台裏で」プラグインするだけで、アプリの残りの部分が詳細を認識しないようにしたいと考えています。基本的に、アプリはデータがキャッシュされていることやキャッシュ方法を認識すべきではなく、データを要求してデータを取得するだけです。
だから私の質問は、これを実装するための良い戦略は何ですか? 誰かが前にこのようなことをしたことがありますか? 努力する価値はありますか？Core Data 自体がストアを抽象化する方法であることを理解しています。しかし、ある日、Core Data の代わりに NSCoding を使用してオブジェクトをディスクに保存することにした場合について考え続けています。私は通常、すべてのクラスに実装の詳細を知らせるのは好きではありません (この場合、コア データを使用する場合とコア データを使用しない場合)。
どのアプローチが最適かについて少し悩んでいます。長期的には意味をなさない可能性のあるソリューションに多くの時間を投資したくありません。
一般に、Core Data API をコードで直接使用することは理にかなっていますか? それとも、サーバー データとローカル データの両方を処理するカスタム DataManager の背後にあるこれらすべての詳細を抽象化するのが最善でしょうか。
考え？