Практические руководства новичка Данных Ядра какао

First, as Apple's documentation (and recurring comments from Apple engineers) state, Core Data is an "advanced" Cocoa technology. Grokking Core Data requires knowledge of a lot of Cocoa paradigms and patterns. Seriously, learn Cocoa first. Then write a project (or several) without Core Data. Then learn Core Data. Seriously.

To quiet your curiosity, I'll take a stab at the CRUD answer, though it's not going to be the answer you want. The answer is that there is no CRUD pattern for Core Data, at least not the way you think of it. The reason is that Core Data is not a data access layer. It is an object graph management framework. That means the explicit, intended job of Core Data is to manage a graph of object instances. This graph has constraints (such as cardinality of relationships or constraints on individual instance attributes) and rules for cascading changes (such as a delete) through the graph. Core Data manages these constraints. Because an object graph may be too large to be stored in memory, Core Data provides an interface to your object graph that simulates[1] an entire object graph in memory via faulting (object instances are not "faults" when first brought into a managed object context and are "fired" to populate their attributes from the persistent store lazily) and uniquing (only one in-memory instance of a particular entity instance (in the persistent store) is created in the context).

Core Data just happens to use an on-disk persistent store to implement the interface of a large object graph. In the case of an SQLite persistent store, this implementation just happens to use a SQL-compatible database. This is an implementation detail, however. You can, for example create an in-memory persistent store that does not persist anything to disk but allows Core Data to manage your object graph as usual. Thus, Core Data is not really a data access layer. To think of it in these terms will miss it's true power and will lead to frustration. You can't use Core Data with an arbitrary data base schema (this is why all Core Data tutorials start with creating the NSManagedObjectModel). You shouldn't use Core Data as a persistence framework and use a separate model layer; you should use Core Data as a model layer and take advantage of Core Data's ability to persist the model's object graph to disk for you.

That said, to create an NSManagedObjectContext (which provides the object graph interface I described above):

NSManagedObjectModel *mom = [NSManagedObjectModel mergedModelFromBundles:[NSArray arrayWithObject:[NSBundle mainBundle]]]; // though you can create a model on the fly (i.e. in code)
NSPersistentStoreCoordinator *psc = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:mom];

NSError *err;

// add an in-memory store. At least one persistent store is required
if([psc addPersistentStoreWithType:NSInMemoryPersistentStore configuration:nil URL:nil options:nil error:&err] == nil) {
  NSLog(@"%@",err);
}

NSManagedObjectContext *moc = [[NSManagedObjectContext alloc] init];
[moc setPersistentStoreCoordinator:psc];

(note that I'm assuming you're using Garbage Collection; this code leaks in a manual memory management environment).

To add an entity instance (continuting with moc from above):

NSEntityDescription *entity = [NSEntityDescription entityForName:@"MyEntity" inManagedObjectContext:moc];  
//entity will be nil if MyEntity doesn't exist in moc.persistentStoreCoordinator.managedObjectModel

NSManagedObject *obj = [[NSManagedObject alloc] initWithEntity:entity insertIntoManagedObjectContext:moc];

Notice that you need an entity description to create a managed object (why tutorials start with the model) and that you can't create a managed object without a managed object context.

To update an entity instance:

[obj setValue:myValue forKey:@"attributeKey"]; //or use any method on `obj` that updates its state
NSError *err;
if(![moc save:&err]) {
  NSLog(@"%@", err); // an erro occurred in saving, perhaps due to optimistic locking failure
}

To delete an entity instance:

[moc deleteObject:obj];
if(![moc save:&err]) {
  NSLog(@"%@", err); // an erro occurred in saving, perhaps due to optimistic locking failure
}

[1]: For binary or XML persistent stores, the entire graph is stored in memory

Я бы выбрал следующий путь:

1. Выполните общее руководство по Apple Cocoa: Конвертер валют
2. Затем погрузитесь в версию Cocoa Bindings этого руководства (привязки очень удобны и очень важны, если вы переходите к Core Data)
3. Cocoa Dev Central's "Создайте ядро Data App " учебное пособие

Дополнительная литература:
Как всегда: книга Программирование какао для Mac OS X
Архитектура приложений на основе документов (ADC)
И наконец: сравнение некоторых аспектов Cocoa и .net

Doesn't look like anyone's mentioned these books yet:

• Core Data by Marcus Zarra, The Pragmatic Programmers
• Core Data for iPhone by Tim Isted, by Addison-Wesley (which, yes, is an iPhone book, but most of the principles of Core Data are shared across platforms)

Для гаек и болтов вы можете найти Apple Core Data Basics полезными - там также есть руководство по созданию утилиты без графического интерфейса.

Core Data на самом деле не является уровнем доступа к данным (подробнее см. Мой другой ответ). Но что, если вы хотите уровень доступа к данным для Какао? Какие у вас есть варианты? Я профессиональный разработчик Cocoa и Qt, и до сих пор мне удавалось избегать корпоративного мира Windows или Java, поэтому моя оценка вариантов может не совпадать с вашей. Исходя из корпоративной экосистемы, я ожидаю, что вы найдете варианты немного пугающими. Я заказал их в том виде, который, как я ожидаю, будет для вас наиболее или наименее пугающим (примерно от самого до минимального какао-y, а также примерно от самого до наименее знакомого для меня). Найдите место в списке, где ваш желудок перестает дергаться, и вы нашли свое решение ...

1. Хотя Core Data - очень мощная структура для управления графом объектов компонента модели архитектуры MVC, вы не обязаны его использовать. Вы можете написать свой собственный модельный слой и по-прежнему играть в мире Cocoa MVC. Так мы делали это до Core Data. Вы по-прежнему можете использовать какао NSObjectController , NSArrayController и NSTreeController , если хотите. Таким образом, вы можете развернуть свой собственный уровень доступа к данным, используя собственные API C / C ++ от поставщика базы данных.

2. Фреймворк BaseTen - это коммерческий лицензированный API, подобный Core Data, поверх серверной части PostgreSQL. . Это действительно больше ORM, чем структура управления графом объектов, такая как Core Data, но API похож. Насколько я понимаю, он может обрабатывать существующую (произвольную) схему или использовать модели управляемых объектов Core Data. Они предоставляют свой собственный подкласс NSArrayController , который вы можете использовать в качестве замены для контроллера массива Cocoa. Я никогда не использовал BaseTen лично, поэтому не могу говорить о его полезности, но слышал хорошие отзывы. Насколько мне известно, это только PostgreSQL.

3. Мост Python-Objective-C, называемый PyObjC, является достаточно зрелым и поставляется с OS X начиная с 10.5. Используя этот мост, вы можете написать полные приложения Cocoa на Python или написать гибридное приложение Python / Objective-C. Используя PyObjC, вы можете использовать любую из ORM Python, такую ​​как SQLAlchemy , для реализации уровня вашей модели. Опять же, не без работы, но, возможно, все еще относительно легко для компетентного программиста на Python и Какао.

4. Apple Enterprise Object Framework, часть WebObjects, теперь представляет собой Java ORM, имеющую в своем происхождении ORM Objective-C. Я считаю, что вы все еще можете писать настольные приложения с помощью WebObjects. Я понимаю, что многие шаблоны Какао переносятся, но это совсем другой зверь. Я никогда не писал код WebObjects, поэтому не могу дать вам больше советов по этому поводу.

5. Вы можете использовать кросс-платформенный инструментарий. Qt может создавать прилично выглядящие пользовательские интерфейсы Mac (хотя см. Ниже). Qt также имеет структуру уровня модели, которая включает поддержку SQL для нескольких баз данных в модуле QtSql . Qt вовсе не Cocoa . Пользователи Savy Mac не любят неродные приложения. Qt примерно так же хорош, как и для кроссплатформенности на OS X, но не идеален. Если вы можете оставаться родным, сделайте это.

6. Всякая чушь Java Swing / SWT. Опять же, это мощная штука, но на Mac она выглядит адом, и пользователям она не нравится.

7. Mono в OS X относительно незрел, и я не знаю, каков статус любого из ORM .Net в Mono. Хотя на это стоит взглянуть. Что касается пользовательского интерфейса, то материал Mono-GTK выглядит довольно плохо в OS X. Для Qt существует привязка C # под названием Qyoto, которая работает на Mono.