通常、シングルスレッドアプリケーションでは、メインの管理対象オブジェクトコンテキストはAppDelegateに存在し、appDelegate.mainMOCを介してアクセスします。しかし、Appleがネストされたコンテキスト（親と子）を導入したので、彼らは「バトンを渡す」アプローチを推奨しています。
ネストされたコンテキストでは、アプリケーションデリゲートから直接取得するのではなく、コンテキストにアクセスする「バトンを渡す」アプローチを採用することがこれまで以上に重要になります（あるビューコントローラーから次のビューコントローラーにコンテキストを渡すことによって）。
しかし、ネストされたコンテキストを導入することで、それが「これまで以上に重要」になる方法はよくわかりません。AppDelegateに3つのコンテキスト（masterMOC、mainMOC、extraMOC）を含めることができないのはなぜですか？それの問題は何でしょうか、そしてなぜAppleはそのアプローチに反対することを勧めているのですか？
そもそも、アプリのデリゲートにそれらすべてを含めることは悪い考えでした。それはあらゆる種類のソフトウェア設計ルールを破ります。
そうは言っても、どのコンテキストがどのようなものかを正確に知る必要がある場所全体にコードを書く必要はないという考えです。提案されたソリューションでは、すべてのコードがmoc1、moc2、またはmoc3を使用することを知っている必要があります。 。それは非常に壊れやすいです。
理想的には、MOCをコードに渡し、そのコードは指定されたMOCを使用します。スクラッチを作成する必要がある場合は、渡されたMOCの子を作成できます（もちろん、MOCが閉じ込めタイプではないと仮定します）。
1つのアプローチは、オブジェクトを渡すことであり、正確なMOCについて心配する必要はありません。必要に応じて、管理対象オブジェクトのmanagedObjectContextプロパティをクエリするだけです。
アプリデリゲートにデータを保持するということは、それを「キッチンシンク」として使用していることを意味し、ある意味では、単にグローバル変数を称賛していることに注意してください。
ところで、新しいスレッドポリシーはより厳格であり、スレッドを間違えた場合にコードが恐ろしい死を遂げることがほぼ確実であるため、これは「これまで以上に重要」です。