Core Dataオブジェクトへの参照を回避するのは悪いですか？

Question

ビューコントローラ内の管理対象オブジェクトへの参照を有効にしておくことは賢明ですか？

私はCore Dataには比較的新しいので、最近別のコンテキストの管理オブジェクトを混在させることができないことを発見しました。コンテキストに属さないオブジェクトをリレーションシップに追加することはできません。

たとえば、古典的なEmployeeエンティティと、Employeeオブジェクトを強く参照しているEmployeeDetailsViewControllerがあるとします。

Employeeオブジェクトの代わりに従業員のIDを格納する必要がありますか？ドメインオブジェクトの代わりにIDを使って作業するのはむしろ不便なので、通常どのように行われているのか不思議でした。

Answer 1

コアデータの世界へようこそ！

まず、アプリケーション内に多くのNSManagedObjectContextインスタンスがあります。ユーザーインターフェイス全体がONEのコンテキストで実行されているはずです。それはあなたの関係の問題を解決します。

参照を保持することについては、他のスレッドからそのオブジェクトを削除する可能性がある場合には、を除き、を除いて問題はありません。バックグラウンドスレッド（ネットワーク操作など）から削除する状況がある場合、困難な状況に陥る可能性があるため、これらのオブジェクトに対する強力な参照を保持したくない可能性があります。

ある種の変更に別のコンテキストを設定することをお勧めします。サーバーから来るもの、そして例えばサーバーからのもの。ユーザーの変更（UIを通じて作成）？私は、アプリケーションの "同期オフラインの変更"種類の機能と別々にこれらの2つのタイプの変更を追跡する方法を把握しようとしているので、例えば、サーバーから来る変更は、ユーザーが同じオブジェクトを変更した場合に破棄される。 （どのような長いコメントを！）（あなたはまた、同期についての私の他の質問を見てみることができます）

をだから私は住んでルール：

• もしUI。メインキューコンテキスト。例外なし
• UIでない場合、プライベートキューコンテキスト。例外なし

私は通常、メインキューコンテキストの子として自分のプライベートキューコンテキストを持っており、コード量を削減し、対処する必要があります。

したがって、サーバーの同期はUIではなく、プライベートの子コンテキストに対して実行する必要があります。

詳細については、MVC-Nの話をご覧ください。

Answer 2

オブジェクトを保存していることを忘れないでください。大丈夫です。
私はほとんどのアプリでこれが好きです。最初に選択したメインユーザがrootControllerの中に保存されているので、プログラムの使用中に変更されないので、CoreDataへの呼び出しが多すぎることはありません。

エンティティがアプリ内で変更された場合は、保存したオブジェクトをCoreDataから更新する必要があります。