Контекст родитель-потомок основных данных многоуровневый

в моем приложении у меня есть 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

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

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

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

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

спасибо

6
core-data ios nsmanagedobjectcontext objective-c

2 ответов

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

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

иногда полезно думать о MOC как о сеансе или блокноте. Сопоставление не между Moc и сущностями, а скорее между МОК и логическими единицами работы.

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

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

4

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

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

для детализации просто передайте контекст контроллеру дочернего представления. Ваши контроллеры дочернего вида fetched results controller могут используйте тот же контекст, что и контроллер родительского представления. Многочисленные примеры кода Apple используют именно этот шаблон.

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

-1