tags:

views:

133

answers:

3

I'm developing an application that needs to store lots of records in an organized way. Specifically, I'm writing a personal finance app. As you can imagine, this app will contain records of financial transactions that must be sorted in various ways: by date, by amounts, by recipient, by account, etc. And of course, the app will need to quickly get, say, all transactions between certain dates, quickly sum up some records, and so forth.

I'm still in the design phase, and I'm planning to use SQLite as the backend storage for the app, since OS X already ships with a SQLite framework. I thought to myself that it might be nice to abstract out the database-connection layer so that I may re-use the code in other projects, and then I thought that maybe someone else may have already done this.

Then I thought it might not be a good idea at all. I've read a little bit about CoreData on OS X, and thought that maybe I should be using CoreData for this purpose. However, I don't know if CoreData really fits my goals. It seems more like a way to abstract out an app's controllers and tie UI widgets to models, rather than providing an API to make it fast and easy to run possibly complicated queries on structured data.

So my question is really three related parts:

  1. Is there an ORM for Cocoa? I'm looking for something like Django's ORM layer, or Rails' ActiveRecord. (I only need it to connect to SQLite databases, though.)
  2. Or should I just use CoreData for this? Will it fit my needs well?
  3. Or am I barking up the wrong tree, and should be looking at another framework that accomplishes my goals with a different technique?
A: 

You should use CoreData. It works with SQLite-like queries.

Ben Gottlieb
+4  A: 

The closest thing to an ORM that ships with Cocoa is CoreData. It's not quiet an ORM though, but more an in memory object graph that can be serialized to disk.

It uses a general Model based layout and you can add helper functions and the like to said models. It can maintain referential integrity and the like as well, and requires no SQL to be used.

It can have one of three storage backends, the recommended one being SQLLite. I almosted used it for my current app. However, I found after testing a while with it that it was too heavy. This is supposed to be much better off in 10.5+, however I'm targeting 10.4 and I just found it to be too memory hungry/slow for my uses.

As far as querying it, you do most (all?) queries via NSPredicates, and then you can use a foreignKey style construct to access related models. It can be quiet useful.

Is it as full featured as ActiveRecord, Django's ORM, or SQLAlchemy? No. But it's pretty good.

I'd recommend prototyping with it and trying to see how it works out for you. For further reading, I'd recommend the Core Data Book from the Pragmatic Bookshelf. I've read it and found it in general to be very helpful in understanding Core Data.

Bryan McLemore
+1  A: 

Is there an ORM for Cocoa? I'm looking for something like Django's ORM layer, or Rails' ActiveRecord. (I only need it to connect to SQLite databases, though.)

Technically, no.

Or should I just use CoreData for this? Will it fit my needs well?

You can try, but CoreData is not likely a good fit. CoreData has some ORM like features, but is not really an ORM.

Or am I barking up the wrong tree, and should be looking at another framework that accomplishes my goals with a different technique?

There are alternatives, but nothing that approaches a native Cocoa ORM. One such option is to use a Java ORM like Hibernate which you then call from your Cocoa code.

In reality, you don't need an ORM. You could build a simplistic ORM yourself on top of the OSX SQLLite framework. If you then open sourced your simplistic ORM, this question would have a better answer. :)

Michael Maddox