10

我是一大群热衷于尝试 Mac OS X 开发的未洗过的 .NET 开发人员之一。目前，我正在尝试找出 Cocoa 的各种元素，并且有点卡在 Core Data 上。

我注意到 Web 上可用的大多数文档和资源都涉及广泛的端到端教程，从模型、生成类、基于文档的 UI 等开始。似乎没有足够的注意力集中在每一位上，或者至少没有足够的例子。

有人可以为我指出正确的方向，无论是在线资料还是书籍，都可以给我各种细节的详细说明？也许我被困在 .NET 世界中，但我仍然认为数据访问层等方面。我想知道“CRUD”的基础知识，在设置持久存储、创建实体、编辑、保存方面存储等。只是基础知识，没有详细说明 UI。如果我可以对各个位进行单元测试，那就太好了。

我想我在这里试图进入正确的心态——那里的任何 .NET 开发人员都知道适合像我们这样正在研究 Cocoa 编程的人的阅读材料吗？

非常感谢，丹妮。

4

6 回答 6

15

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

于 2009-11-11T19:19:34.203 回答
8

我会采取以下路线：

  1. 做一般的Apple Cocoa教程： 货币转换器
  2. 接下来，深入了解该教程的Cocoa Bindings 版本（如果您继续学习 Core Data，Bindings 非常方便且非常重要）
  3. Cocoa Dev Central 的“构建核心数据应用程序”教程

进一步阅读：
一如既往：Cocoa Programming for Mac OS X
Document-Based Application Architecture (ADC)一书
最后：Cocoa 和 .net 某些方面的比较

于 2009-11-11T09:41:35.900 回答
5

Core Data 确实不是数据访问层（有关更多信息，请参阅我的其他答案）。但是，如果您想要Cocoa 的数据访问层怎么办？你有什么选择？我是一名专业的 Cocoa 和 Qt 开发人员，到目前为止，我已经设法避开了 Windows 或 Java 企业世界，因此我对选项的评估可能与您的不完全相符。来自企业级生态系统，我希望您会发现这些选项有点可怕。我已经订购了它们，我预计它们对你来说是最不可怕的（大约是最不可怕的 Cocoa-y，所以对我来说也大致是最熟悉到最不熟悉的）。在列表中找到你的胃停止蠕动的地方，你就找到了解决方案......

  1. 尽管 Core Data 是一个非常强大的框架，用于管理 MVC 架构的模型组件的对象图，但您没有义务使用它。您可以编写自己的模型层，并且仍然可以在 Cocoa MVC 世界中玩耍。这就是我们在 Core Data 之前的做法。如果需要，您仍然可以使用 Cocoa NSObjectController、NSArrayController和NSTreeController。因此，您可以使用数据库供应商的本机 C/C++ API 推出自己的数据访问层。

  2. BaseTen框架是商业许可的类似Core Data 的 API，位于 PostgreSQL 后端之上。它实际上更像是一个 ORM，而不是像 Core Data 这样的对象图管理框架，但 API 是相似的。我的理解是它可以处理现有（任意）模式或利用 Core Data 托管对象模型。它们提供了自己的NSArrayController子类，您可以将其用作 Cocoa 数组控制器的替代品。我从未亲自使用过 BaseTen，所以我不能谈论它的实用性，但我听说过好东西。据我所知，它只是 PostgreSQL。

  3. Python-Objective-C 桥，称为 PyObjC，非常成熟，自 10.5 起随 OS X 一起提供。使用这个桥，您可以用 Python 编写完整的 Cocoa 应用程序或编写混合 Python/Objective-C 应用程序。使用 PyObjC，您可以使用任何 Python ORM（例如SQLAlchemy）来实现模型层。同样，对于一个称职的 Python 和 Cocoa 程序员来说，不是没有工作，但可能仍然相对容易。

  4. Apple 的企业对象框架是 WebObjects 的一部分，现在是一个 Java ORM，其沿袭有一个 Objective-C ORM。我相信，您仍然可以使用 WebObjects 编写桌面应用程序。我知道许多 Cocoa 模式会延续，但这是一个非常不同的野兽。我从来没有写过 WebObjects 代码，所以我不能给你更多的建议。

  5. 您可以使用跨平台工具包。Qt可以生成看起来不错的 Mac UI（尽管见下文）。Qt 还有一个模型层框架，包括对QtSql模块中多个数据库的SQL 支持。Qt根本不是 Cocoa 。Savy Mac 用户不喜欢非本地应用程序。Qt 与 OS X 上的跨平台性能差不多，但并不完美。如果你能保持原生，那就去做吧。

  6. 任何 Java Swing/SWT 废话。同样，这是强大的东西，但它在 Mac 上看起来就像地狱，用户不喜欢它。

  7. OS X 上的 Mono 相对不成熟，我不知道 Mono 上的任何 .Net ORM 的状态如何。不过，这是值得一看的。至于 UI，Mono-GTK 的东西在 OS X 上看起来很糟糕。有一个用于 Qt 的 C# 绑定，称为 Qyoto，它在 Mono 上运行。

于 2009-11-12T07:05:18.193 回答
4

似乎还没有人提到这些书：

于 2009-11-11T19:32:54.657 回答
1

不过，对于具体细节，您可能会发现 Apple 的Core Data Basics很有用——那里还有一个用于构建无 GUI 实用程序的教程。

于 2009-11-11T17:19:45.817 回答
0

苹果销售电器和名人产品（好莱坞），它们与企业发展完全无关，如果您正在寻找 delphi/vcl 或 .net 级别的任何东西，可可甚至在完成之前就被放弃了，因为机会主义的可可触摸，祝你好运（他们没有这种东西）

ps 这就是为什么苹果在服务器端和/或企业桌面端没有发言权，也就是说，他们没有线索，也永远不会。也就是说，他们从事不同的业务。甚至他们的内部系统都是基于 linux 的（只是为了让你知道！）

于 2013-11-16T19:11:32.263 回答