Наследование объектов Core Data --› ограничения?

Я считаю ошибкой проводить параллель между сущностями и классами. Несмотря на то, что они очень похожи, у них есть некоторые важные отличия.

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

Многие считают, что наследование классов должно происходить параллельно с наследованием сущностей. Это не. Пока класс происходит от NSManagedObject и отвечает на правильные сообщения ключ-значение для объекта, который он представляет, у класса может быть много веселых приключений в его наследовании, которые не отражаются в наследовании сущностей. Например. Довольно часто создается пользовательский базовый класс прямо под NSManagedObject, и все последующие подклассы управляемых объектов наследуются от него независимо от их сущностей.

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

Owner{
  vehical<-->Vehical.owner
}

Vehical(abstract){
  owner<-->Owner.vehical
}

Motocycle:Vehical{ 

}

Car:Vehical{

}

Теперь Owner.vehical может содержать объект Motocycle или объект Car. Обратите внимание, что наследование классов управляемых объектов для Motocycle и Car не обязательно должно быть одинаковым. У вас может быть что-то вроде Motocycle:TwoWheeled:NSManagedObject и Car:FourWheeled:NSManagedObject, и все будет работать нормально.

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

Я подумал, что было бы полезно упомянуть, что приложение Notes в iOS 10 использует наследование в своей модели Core Data. Они используют базовый объект SyncingObject, который имеет 7 подобъектов, включая Note и Folder. И, как вы упомянули, все они хранятся в одной и той же таблице SQLite, которая имеет колоссальные 106 столбцов, и, поскольку они являются общими для всех объектов, большинство из которых имеют значение NULL. Они также реализовали отношение «один ко многим» в папках как «многие ко многим», которое создает сводную таблицу, что может быть решением проблемы наследования.

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

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

Как вы также заметили, все объекты помещаются в одну таблицу.

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

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