A NYC .NET Developer in Steve Jobs' Court - Day 2 (Core Data)

If you're as new to Core Data as I am, check out this video tutorial, I found it extremely useful.

I have been able to produce the currency converter sample in OS X Tiger and I was fairly pleased. I was surprised by how much of the plumbing took place in the NIB and how little took place in the code. I like that. If you're an old hat at .NET, you'll know that even with the advent of partial classes, you still have code lingering around somewhere that has hundreds of lines that look like this:

myControl.Click += new EventHandler(....blah );

I have no idea which I like better, though I can imagine how the loosely coupled message sending facilities of Objective-C on the Cocoa frameworks allows for some pretty reusable code as well as UI. In other words, I think it would be easier to take a GUI that performed a set of tasks and re-use it in another application because the NIB is not only isolated, but can be plugged into any xcode project. I'm sure all you Apple programmers are thinking, "*yawn*" , but hey - I'm new here.

For my next foray into the unknown (which is a pretty unusual spot for me to be in... I've been programming .NET for so long, I am unaccustomed to feeling lost and overwhelmed by a programming environment) I decided to take a whack at Core Data. Core Data is, I believe, something that was introduced in OS X 10.2 or 10.3. Case in point, the big SAMS book I have on Cocoa written for 10.1 doesn't have a single word referring to Core Data. I'm hoping the one someone from a previous post recommended (en route to me now) will have more information on Core Data.

It's tough to pinpoint a good comparison for Core Data. You could actually consider Core Data to be in the same category as the ADO.NET Entity Framework that is still in CTP status. The ADO.NET EF creates an abstraction layer above the physical data model and allows you to define entities, attributes, and relationships between entities. The EF will happily map entities to underlying SQL Server (potentially other providers will be available in the future). Core Data also allows you to define entities, entity relationships, and attributes on those entities. I think the main difference is that those entities are your data model and Core Data allows you to persist your model as binary, XML, or SQL.

Here's a sample scenario to compare the two:

You have some software like Quicken or MS Money. You have bank accounts, and you have a ledger that contains a list of transactions. Each transaction belongs to a given bank account, but also has been assigned a category. Anybody with any exposure to relational databases is probably already envisioning the data structure for this app.

• In C#, using the ADO.NET Entity Framework, I would create three entities: Account, LedgerItem, and Category. In the account entity there's an AccountID column that is an autoincrement, indexed, primary key that serves as the source of a relationship to the LedgerItem entity. The relationship would probably be called LedgerItems so that I can refer to child items simply by doing myAccount.LedgerItems once I have called the method that pulls child rows (the EF is a lazy-loader, child rows are only obtained by the parent by explicit method calling or by requiring their presence in an eSQL or LINQ query). Accordingly, there is a AccountID attribute in the LedgerItem entity. Under the hood, there are three different XML files that create the entity mapping and persistence information. There's the schema layer XML file that defines the actual underlying physical storage mechanism (e.g. the SQL tables and their structures). There's the mapping XML file that maps the physical data in the underlying database to the entities, and finally there is the entity XML which defines the entities themselves. The entities defined in the entity layer are then compiled into classes that can be used as the source for LINQ queries as well as eSQL (Entity SQL) queries, or even hit the "old fashioned way" and turned into DataSets, etc. Some of the advantages here are that in a big enterprise environment where you've got a truly remote back-end, this kind of abstraction on top of stored procedures and raw data is extremely useful and makes for some really clean-looking back-end code, which is always good for maintenance and enhancement.
• When I set this same scenario up in Core Data, I suffered from some serious culture shock. First thing you do is set up the entities and their attributes (e.g. Account, LedgerItem, and Category). Here's where I screwed up big-time: I created individual ID columns just like you would in a relational database. So, I created an accountId, a ledgerItemId, etc. And I kept trying to create relationships based on that column and Interface Builder was having none of that. It rejected me like a bad organ transplant. Eventually I realized that because Core Data does all three: persistence, retrieval, and entity mapping - it doesn't need the artificial ID columns to link related items. It can manage that information internally when related items are added through the relationship itself. So, I ended up defining three entities with only the attributes that applied to them. Then, I created a ledgerItems relationship to get ledger items for a given account, and linked the inverse relationship so that I can use account to get back to the parent account. Also created a category relationship to get the category for a given ledger item. It was all extremely smooth and I found the process of designing my data model directly within my code tool to be extremely enjoyable.

At this point I was thinking I was looking at really two different takes on the same concept - object-relational mapping. The Entity Framework from Microsoft and Core Data from Apple. It also seemed pretty obvious that the Entity Framework is designed specifically for dealing with data contained externally in relational databases while Core Data is designed specifically for storing data on the local disk for desktop applications. I think its hard to say which one is "better" since they both tackle two different problems. However, I did love the fact that I didn't have to set up this completely arbitrary identifier columns that served only to link related entities - Core Data links them for me without creating excess "baggage" on the entity.

The next thing I did was create some GUI that was bound to my objects. I did this both in Leopard and in Tiger. I can't discuss the Leopard experience, but it hasn't changed so radically that my description of the Tiger experience is invalid. Basically I used an NSTableView, created an Array Controller, bound the array controller to the list of Account entities and then bound the table view to the array controller. For each column, I set the value binding to a model expression like accountName for the account name, etc. Within about 5 minutes, I had a grid in my window and was able to click my "Add" and "Remove" buttons to actually create new accounts and manipulate their data. You can do the same thing in C# 2005 with the data navigation control, object data providers, and a couple lines of code rigged up to the navigator's add and remove buttons.

Here's what I liked about the Cocoa experience more than the C# experience:

• Everything was contained either in the NIB file or in the data model file. It all felt very neat, clean, and separated.
• Because I had created a 'document' style project, I immediately got save and load to/from disk file functionality for free, in Binary, XML, and SQL format.

So, in short, my experience with Core Data was pleasant. The whole thing just felt very smooth and I got the feeling that it would feel as smooth for an application with 40 entities as it does for an application with 2 entities. You can do pretty much everything in C# 2005 with the EF that you can do with Core Data, but there is really no compelling object-relational system for "desktop applications" (aside from targeting MSDE in your entity mapping schema) that is built-in "out of the box" in .NET, whereas Core Data fills that need but lacks in its ability to communicate with remote relational databases.

Anyway - I am still looking for showstoppers or blockbusters - things that either make me want to run screaming away from Cocoa programming or things that make me want to abandon C# programming. So far I have found neither and will keep looking as I learn more Objective-C and Cocoa.

tags: apple  mac  osx  coredata  cocoa  objectivec  programming  

links: digg this    del.icio.us    technorati    reddit