Cocoa Core Data newbie how-tos

Question

I am one of the great unwashed masses of .NET developers keen to try their hands at Mac OS X development. At the moment I am trying to figure out the various elements of Coc

Answer 1

Core Data really isn't a data access layer (see my other answer for more). But what if you want a data access layer for Cocoa? What are your options? I'm a professional Cocoa and Qt developer and so far I've managed to avoid the Windows or Java enterprise world, so my evaluation of the options may not match yours exactly. Coming from an enterprise-y ecosystem, I expect you'll find the options a little scary. I've ordered them in what I expect will be most to least scary for you (roughly most to least Cocoa-y and so also roughly most to least familiar for me). Find the spot on the list where your stomach stops lurching and you've found your solution...

1. Although Core Data is a very powerful framework for managing the object graph of the model component of an MVC architecture, you're not obligated to use it. You can write your own model layer and still play in the Cocoa MVC world. This is how we did it before Core Data. You can still use the Cocoa NSObjectController, NSArrayController, and NSTreeController if you want. Thus, you can roll your own data access layer using the native C/C++ APIs of your data base vendor.

2. The BaseTen framework is a commercial licensed Core Data-like API on top of a PostgreSQL backend. It is really more of an ORM than an object graph management framework like Core Data, but the API is similar. My understanding is that it can handle existing (arbitrary) schema or make use of Core Data managed object models. They provide their own NSArrayController subclass that you can use as a drop in replacement for Cocoa's array controller. I've never used BaseTen personally, so I can't speak to its utility, but I've heard good things. As far as I know it's PostgreSQL only.

3. The Python-Objective-C bridge, called PyObjC, is quite mature and ships with OS X since 10.5. Using this bridge you can write complete Cocoa apps in Python or write a hybrid Python/Objective-C app. Using PyObjC, you could make use of any of the Python ORMs such as SQLAlchemy to implement your model layer. Again, not no work but perhaps still relatively easy for a competent Python and Cocoa programmer.

4. Apple's Enterprise Object Framework, part of WebObjects, is now a Java ORM that has an Objective-C ORM in its lineage. You can, I believe, still write desktop apps using WebObjects. I understand that many Cocoa patterns carry over, but this is a very different beast. I've never written WebObjects code, so I can't give you much more advice on this one.

5. You can make use of a cross-platform toolkit. Qt can produce decent looking Mac UIs (though see below). Qt also has a model-layer framework that includes SQL support for several data bases in the QtSql module. Qt is not Cocoa at all. Savy Mac users don't like non-native apps. Qt is about as good as it gets for cross-platform on OS X, but it's not perfect. If you can stay native, do it.

6. Any Java Swing/SWT crap. Again, this is powerful stuff, but it looks like hell on the Mac and users don't like it.

7. Mono on OS X is relatively immature and I don't know what the status of any of the .Net ORMs are on Mono. It's something to take a look at though. As far as UI, the Mono-GTK stuff looks pretty bad on OS X. There is a C# binding for Qt called Qyoto which runs on Mono.