Основные данные Многоуровневый родительский - Детский контекст

Question

В моем приложении у меня есть UITableViewController, который показывает список событий. Этот контроллер использует ManagedObjectContext Say ParentContext. Теперь, если выбрано какое-либо событие, отображается подробный контроллер просмотра, где пользователи могут редактировать детали события. Таким образом, я создал контекст ребенка сказать,

ChildContext with type "NSPrivateQueueConcurrencyType"

ChildContext whose parent Context is "ParentContext".

Мой код:

NSManagedObjectContext *childContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType]; 
    childContext.parentContext = self.context ; 

Теперь снова есть некоторые поля и отношения, которые необходим другой бур вниз. Таким образом, я создал еще один ChildContext для нового контроллера представления говорят,

GrandChildContext with type "NSPrivateQueueConcurrencyType"

GrandChildContext whose parent context is "ChildContext"

этот процесс идет на другом уровне (всего 4 уровня от родительского (Tableview) к ребенку)

self.context - Parent Context 
    | 
    | 
ChildContext 
    | 
    | 
GrandChildContext 
    | 
    | 
GrandGrandChildContext 

---

Моя сущность выглядит следующим образом

EntityA   -- (Edit View Controller - uses ChildContext) 
| 
|- Field1 
| 
|- Field2 
| 
|- RelationShip (1 to Many) - (Relationship Add/Edit View Controller - uses GrandChildContext) 
    | 
    |- Field1 
    | . 
    | . 
    |- Field3 
    | 
    |- Relationship (1 to Many) - (Relationship Add/Edit View Controller - uses GrandGrandChildContext) 
      | 
      |- Field1 
      | 
      |- Field2 

Это правильный способ использования родительского - детского контекста? Потому что в один момент времени у меня будет 1 NSMainQueueConcurrencyType MOC and 3 NSPrivateQueueConcurrencyType MOC.

Если это не так? Есть ли другой путь?

Слишком много детского контекста влияет на производительность приложений?

Первоначально я использовал свойства и NSArrays для управления введенными пользователем данными, и когда пользователь нажимает кнопку «Сделано», я буду обновлять/создавать управляемые объекты. Но это утомительная работа, из-за которой мой диспетчер просмотра грязный. Поэтому я переключился на контекст родителя-ребенка, который очень легко сохранить или выбросить обновления.

Благодаря

Answer 1

Возможно, вы немного зашли в тупик с несколькими детскими контекстами, но только немного, и ваш общий подход звучит. MOC (контекст управляемого объекта) - довольно легкий объект.

Мне нравится ваш подход, имеющий отдельную ссылку в пределах каждого контроллера/сцены представления к MOC, который применяется к этой сцене.

Иногда полезно подумать о MOC как сеансе или блокноте. Совпадение не происходит между MOC и Entities, а скорее между MOC и логическими единицами работы.

Если один из ваших сокращений отмечает начало некоторой задачи редактирования, которую пользователь может захотеть отказаться или отменить, это хороший момент, чтобы открутить дочерний MOC и передать его новому виду. Вы можете, при необходимости, откат: или даже просто отказаться от MOC, когда вы снова вернетесь к исходной точке.

С другой стороны, если вы просто писали статическую информацию, используйте только один MOC. В этом случае нет необходимости использовать или использовать больше.

Answer 2

Возможно, есть небольшое количество путаницы о лучшем случае использования для вложенных управляемых контекстов объектов. Для вашего случая я бы рекомендовал использовать только один контекст.

Перемещение на основные данные из массивов и т. Д. Было очень хорошей идеей. Теперь развяжите истинную мощность и простоту графического объекта. Старайтесь держать вещи простыми.

Чтобы развернуть, просто передайте контекст контроллеру дочернего представления. Контроллеры дочерних представлений, получающие результаты, могут использовать тот же контекст, что и родительский контроллер представления. Многочисленные примеры кода Apple используют именно этот шаблон.

Единственный раз, когда вам нужны контексты, если вам действительно нужна параллелизм. Это вообще не так. Новый интерфейс контроллера дочернего представления отображается после получения данных. Если это происходит слишком долго (скажем, потому что данные поступают из веб-службы), вы показываете какой-то интерфейс «Подождите» и покажите полный интерфейс после завершения поиска данных. Скорее всего, это не ваш сценарий.