Re: Should I use Core Data?
Re: Should I use Core Data?
- Subject: Re: Should I use Core Data?
- From: Joshua Scott Emmons <email@hidden>
- Date: Thu, 20 Apr 2006 15:37:44 -0500
There are two main points that leave me doubtful. First, my file
format is SVG
Yeah. The big benefit of CD from my point of view is you never have
to mess with files. No archiving, no unarchiving, no open or save
panels... it all just works without thinking about or writing code to
support it. Seeing as your app is wed to SVG (and I, at least, don't
know of any clever hacks to make CD write out SVG files), this
benefit would seem to be a big nil for you.
as this is a drawing application, I have a lot of "non-standard
attributes" - rects, colors, paths, etc. The documentation makes
that sound inconvenient.
I don't find this limitation to be particularly inconvenient.
Inefficient, maybe. But you won't know if it will effect performance
of your app until you profile it. At any rate, the basic deal here is
that CD only stores objects. If your "non-standard" attributes can be
shoved into NSNumber, NSString, or NSData objects, the inconvenience
would be minimal. Instead of storing myRect you'd store
NSStringFromRect(myRect). The code remains pretty readable too.
It would be nice to have the built-in undo support, but it's
actually not clear to me what other benefits I would get.
The built-in undo is VERY nice, but this isn't too big of a problem
to tackle on your own, either. If your current non-core-data model is
sufficiently isolated from the rest of the code, and you only access
your model's values via accessors (or KVC or something else that
calls your accessors), it's reasonably trivial to pop your undo
manager stuff right in there with your getting and setting code.
Then, any time your model gets changed, undo is "automatically"
updated. Just like with CD. With KVO, even tricky scenarios can be
handled with relative ease.
The documentation occasionally mentions the hypothetical example of
a Core Data drawing app, but it sure would be nice to have some
sample code, like a CD version of Sketch.
There's nothing about a "drawing app" that makes it inherently CD
friendly or unfriendly. Drawing apps store data like paths, colors,
points, images, and settings. CD can store all of these data elements
with ease. The thing that is making CD a bad fit for your app is not
the "drawing-ness" of it. It's the app's requirement that it uses a
non-core-data native file format and the app's use of non-object data
in its implementation that make it unsuitable for CD. It could be a
word-processor with similar specs and it would still be equally
unsuited for CD.
What are the deciding factors in the decision to switch to Core Data?
For me, it's the answer to this question: "Do you have to deal with
your Model yourself, or can you let it be managed for you?"
The SVG requirement, at least, seems like it would require you to
manage your Model yourself. So I don't think you'll find CD a good
fit for your project. But that's just me talking from my own
experience. Ultimately, it's a call you or contributers familiar with
your project will have to make.
As an afterthought, the answer to the question "Does your application
rely on ORDERED data?" might also be enlightening. CD doesn't do
"order" real well. If you had a to-many relationship to your App's
layers, for example, and you pulled them all up, they'd be returned
to you in an NSSet. You'd have no idea what order they were
"supposed" to be in. That could be a problem in a drawing app.
This problem is most definitely not insurmountable. All you'd have to
do is include an index property in the Layer entity, and order by
that. But it's not the most elegant solution in the world. Like the
problem with storing ints and rects in CD, it's not exactly
inconvenient (though it comes close, sometimes), but it sure is
inefficient.
Cheers,
-Joshua Emmons
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden