Как я могу сделать все объекты Core Data наследовать от моего класса, а не NSManagedObject? - PullRequest
2 голосов
/ 25 августа 2010

Я создал свой собственный класс, который я хочу использовать Core Data вместо NSManagedObject:

@interface MyManagedObject: NSManagedObject {
  id delegate;
}

Я не могу использовать категорию, так как это объявляет ивара. Все мои объекты базовых данных используют конкретные классы, а не являются экземплярами NSManagedObject. Я использую генератор кода для генерации этих файлов. Вот пример того, как может выглядеть Contact объект:

@interface Contact: NSManagedObject {
}

Я знаю, что могу вручную изменить NSManagedObject на MyManagedObject в этом сгенерированном коде, но мне придется делать это каждый раз, когда я перегенерирую код. Есть ли способ заставить его автоматически использовать мой собственный класс?

Кроме того, #import в любом решении может быть проблемой. В идеале я хочу, чтобы он использовал @class MyManagedObject вместо #import "MyManagedObject.h", поскольку MyManagedObject.h находится в библиотеке, а для заголовка требуется префикс папки (например, #import "MyLib/MyManagedObject.h").


Я попытался создать фиктивный объект в файле .xcdatamodel с тем же именем и указать, что все объекты наследуются от него, но есть две проблемы. Во-первых, он использует #import "MyManagedObject.h", который не может найти по причине, указанной выше. Вторая проблема заключается в том, что я не уверен, что это хорошая идея - обманывать Core Data, думая, что класс наследует от другого объекта Core Data ... даже если я не генерирую файл кода. Я предполагаю, что Core Data может делать некоторые ненужные вещи за сценой, потому что считает, что есть дополнительный класс, от которого унаследованы мои классы.

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

#import "MyLib/MyManagedObject.h"

@interface MyProjectManagedObject: MyManagedObject {
}

... и теперь мои автоматически сгенерированные файлы будут выглядеть так:

#import "MyProjectManagedObject.h"

@interface Contact: MyProjectManagedObject {
}

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

Ответы [ 2 ]

2 голосов
/ 25 августа 2010

Не используйте наследование в вашей модели данных, если вы используете бэкэнд SQL. Из-за реализации бэкэнда SQL он обладает ужасными характеристиками производительности и пространства. (Это рекомендация Apple.)

Возможно, я ошибаюсь (я перепроверю), но я думаю, что вы можете делать то, что хотите, используя только файлы классов и заголовков, не вмешиваясь в модель данных. (Предполагается, что вы на самом деле не хотите хранить свой ivar в бэкэнде данных.) Просто реализуйте MyManagedObject, как вы это сделали, и присвойте своим подклассам MyManagedObject вместо NSManagedObject (например, Contact : MyManagedObject). Обратите внимание, что вам нужно делать это только в заголовочных файлах, а не в реальной модели данных. Компилятор должен выяснить все остальное.

1 голос
/ 25 августа 2010

Посмотрите на MOGenerator.Это поможет, по крайней мере, восстановить файлы классов управляемых объектов: для каждого из них создается два файла.тот, который вы редактируете, и тот, который генерируется автоматически.Когда вы регенерируете второе, первое остается нетронутым.

http://digitalflapjack.com/blog/2010/mar/26/mogeneratorftw/

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...