Основные данные: создание экземпляра «корневого объекта» в приложении на основе документов

#cocoa #core-data #nsobjectcontroller

#cocoa #основные данные #nsobjectcontroller

Вопрос:

Я создаю проект на основе документов, используя Core Data, и столкнулся с тем, что для меня может быть просто концептуальной проблемой, поскольку, хотя я не новичок в Cocoa, это моя первая попытка использовать Core Data. То, что я пытаюсь выполнить, должно быть относительно простым: при каждом запуске нового документа я хотел бы, чтобы создавался новый экземпляр одного из объектов моей модели, который служит в качестве «корневого» объекта.

Что я сделал, так это добавил NSObjectController в мой xib, установил для его режима значение Entity Name (с предоставленным правильным именем объекта), отключил «Подготавливает содержимое» и привязал его контекст управляемого объекта к владельцу файла с помощью managedObjectContext в качестве пути к ключу модели. Чтобы проверить это, я привязал заголовок моего главного окна к объектному контроллеру, используя ключ контроллера в качестве выбора и путь к ключу модели в качестве одного из ключей в моей сущности.

Я знаю, что могу создать свой корневой объект программно, но пытаюсь использовать шаблон посредника, рекомендованный Apple. Я видел инструкции в руководстве для сотрудников отдела в разделе «внедрение шаблона посредника», и подробные шаги — это именно то, что, как мне кажется, я сделал.

Есть мысли?

Редактировать: Возможно, я неправильно сформулировал проблему. Модели создаются в Core Data, а отношения настраиваются так, как мне нужно (с «корнем», дочерними элементами и листьями, с использованием отношений «к одному родителю», отношений «ко многим дочерним элементам» и логического атрибута isLeaf). Моя проблема заключается в обеспечении того, чтобы этот корневой объект создавался как синглтон при каждом запуске нового документа. Между корневым объектом и текущим документом должно быть соотношение 1: 1. Этот корневой объект всегда должен существовать и быть доступен без какого-либо взаимодействия пользователя с целью его создания, а дочерние узлы, которые создаются и присоединяются к корню, являются объектами данных, которые используются приложением и управляются им.

Я реализовал вышеуказанную функциональность программно, но в соответствии с принципами Core Data хотел бы полностью перенять шаблон mediator и не управлять каким-либо созданием объектов данных в логике моего приложения.

Ответ №1:

Если вам нужен «корневой» управляемый объект, подобный тому, который вы найдете в связанном списке или дереве, то вам нужно настроить это в самой модели данных.

По умолчанию модель данных Core Data не имеет определенной иерархии среди объектов. Объекты могут быть связаны, но ни один объект логически не находится «выше» или «ниже» другого. Вы можете получить доступ к объекту in в любых отношениях, начав с любого другого объекта и перейдя по отношениям обратно к желаемому объекту.

Иерархия управляемых объектов нуждается в древовидной структуре, подобной этой:

 Tree{
    nodeName:string
    parent<-->>Tree.children
    children<<-->Tree.parent
}
  

… таким образом, «корневой» объект является единственным Tree экземпляром, который имеет parent==nil .

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

Модель данных предназначена для моделирования объектов реального мира, условий или событий, с которыми имеет дело приложение. Таким образом, логические отношения между сущностями / объектами в модели / графике должны отражать отношения реального мира. В этом случае, если объекты реального мира, которые вы моделируете, не существуют в иерархии с реальным «корневым» объектом, условием или событием, то ваша модель также не должна иметь такового.

Комментарии:

1. На самом деле древовидная иерархия отражает реальную модель, которая была бы применима к этому конкретному проекту.

2. Если это подходит, то это подходит, я просто хотел предостеречь вас от использования древовидной структуры только потому, что она отображается в примерах или может использоваться в другом API.