Вставка и сохранение Методы NSManagedObject данных Основные

Question

Есть ли более простой способ сделать что-то вроде следующего в Core Data:

Entry *entry = [[Entry alloc] init]; 
entry.name = @"An Entry"; 
[entry save]; 

Я понимаю, что вам не придется выделять NSManagedObject, должны вставить непосредственно в как:

Entry *entry = [NSEntityDescription insertNewObjectForEntityForName:@"Entry" 
         inManagedObjectContext:[self managedObjectContext]]; 

Но это много кода. Кроме того, я хотел бы сохранить, просто сообщениями, а не должны сохранить весь контекст:

NSError *error = nil; 
NSManagedObjectContext *managedObjectContext = self.managedObjectContext; 
if (managedObjectContext != nil) 
{ 
    if ([managedObjectContext hasChanges] && ![managedObjectContext save:&error]) 
    { 
     NSLog(@"Unresolved error %@, %@", error, [error userInfo]); 
     abort(); 
    } 
} 

Могу ли я положить их в NSManagedObject абстрактного класса и имеют мои управляемые объекты расширения, что абстрактный класс? В принципе, я просто пытаюсь инкапсулировать больше в свои модели и писать меньше кода в своих контроллерах. Любая помощь оценивается.

Answer 1

Заканчивать

NSManagedObject + ActiveRecord.h

Внутри Restkit: http://restkit.org/

Он основан на:

https://github.com/magicalpanda/MagicalRecord

Я использую в RestKit приложение, но вы может принять его довольно легко.

Успехов

Answer 2

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

Подкласс может содержать любые параметры инициализации/сохранения, которые вы определяете, до тех пор, пока он вызывает инициализатор соответствующего родительского класса.

У вас может быть метод +entity, который может ссылаться на статически определенный контекст (это, конечно, ограничит вас одним контуром управляемого объекта), но это не всегда так плохо, если вы также можете вызвать более примитивные инициализаторы, когда вам нужен второй контекст).

Возможно, у вас даже есть метод +entityWithName:.

Что касается сохранения контекста, вы всегда можете определить подкласс и добавить простой метод -save, который сохраняет контекст и генерирует исключение, если сбой сохраняется. Вы можете сделать это с категорией, расширяющей класс NSManagedObject, а не подкласс.

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

Мне не нравится код, который вы размещены, чтобы сохранить контекст, по нескольким причинам:

• Не определяйте managedObjectContext переменную, которая только указывает на self.managedObjectContext. Почти во всех ситуациях это лишняя строка кода без каких-либо преимуществ. В лучшем случае вы делаете свой код трудным для чтения, в худшем случае вы можете вводить ошибки.
• Почему вы проверяете, является ли это nil? Обычно вам нужно разработать код, чтобы он никогда не был nil. Сделайте проверку nil в конструкторе вашего объекта, и если это nil, это критический сбой. Все ваше приложение совершенно бесполезно для пользователя, и вы должны дать понять пользователю, что они не могут использовать приложение, делая что-то серьезное, например, сбой (предупреждение об ошибке сначала было бы неплохо, но я бы не стал я просто выброшу исключение).
• Почему вы делаете чек на hasChanges? Я не могу придумать много ситуаций, когда вам нужно будет сделать эту проверку. Возможно, ваше приложение позволяет пользователю делать много изменений, а затем сохранять их несколько минут спустя? Это плохо. Контекст должен быть изменен миллисекундами после внесения группы изменений, иначе вы рискуете потерями данных. Ваше приложение может потерпеть крах, у телефона может закончиться заряд батареи, или пользователь может получить телефонный звонок, и ваше приложение потребляет достаточно ОЗУ, чтобы ОС немедленно прекратила его, чтобы отобразить экран «входящего вызова». Вам не нужно проверять наличие hasChanges, потому что вы всегда выполняете операцию сохранения сразу после внесения некоторых изменений.
• Как я уже упоминал ранее, если сбой сохранения не удался, вы должны представить пользователю ошибку, а затем выбросить исключение. Избегайте использования кода развертывания NSLog(), это действительно полезно только для разработки и бета-сборки.