Re: Program Structure
Re: Program Structure
- Subject: Re: Program Structure
- From: "Pelaia II, Tom" <email@hidden>
- Date: Wed, 29 Jun 2011 14:10:51 -0400
- Acceptlanguage: en-US
- Thread-topic: Program Structure
I mentioned CoreData because Jeff said he was using a SQLite database, so CoreData seemed to be a natural fit as it supports SQLite and you can think about objects instead of SQLite calls. I think CoreData provides a clean separation of model logic, offers data abstraction and integrates nicely with Cocoa bindings. It is well worth learning! I guess I didn't appreciate the steep learning curve because I have been using Apple WebObjects for over a decade, and CoreData is conceptually similar enough to WebObjects EOF.
One word of warning is that if you are going to use CoreData, you should definitely consider git for SCM as the Subversion .svn directories will cause you trouble when you create new versions of your model.
On Jun 29, 2011, at 1:55 PM, Jens Alfke wrote:
>
>
>
> On Jun 29, 2011, at 10:00 AM, Pelaia II, Tom wrote:
>
>> CoreData is thew way to go unless you need to have tight control over the database schema. CoreData provides an object representation of your data, data abstraction and natural Cocoa integration.
>
> On the other hand, CoreData may have a steep learning curve for a new developer. (I found it somewhat hard to learn as an experienced Cocoa programmer.) It can also be overkill for small data sets.
>
> For something like an introductory address book app, I’d suggest storing the data as a property list (plist). PLists are conceptually like JSON, and it’s very easy to read and write NSDictionaries and NSArrays to that format. If your data set isn’t too large, you can simply read it from a plist file on launch, work with it as a structure of nested arrays/dictionaries, and then write it back to the plist file after it changes.
>
> Slightly more advanced is using NSArchiver, which is a way to persist object graphs to/from data blobs (similar to Java object serialization, Python’s “pickles”, etc.) This will let you use your own object-model classes, which makes your code a bit cleaner.
>
> (I think some of the AppKit example apps may demonstrate this type of storage. At least, they did back when I learned Cocoa.)
>
> I’ve used the NSArchiver approach for things like storing archives of blog posts. I had a data-set of over 1500 posts in it and the I/O time and memory overhead weren’t a problem, even on the pathetic excuses for computers we had back in 2004 ;-)
>
> I’m not saying anything against CoreData; but there are times when a laser-cutter is the right tool, and times when it’s easier just to use scissors :)
>
> —Jens
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden