Re: whether to use core data...
Re: whether to use core data...
- Subject: Re: whether to use core data...
- From: Jeffrey Oleander <email@hidden>
- Date: Sun, 4 Oct 2009 10:39:42 -0700 (PDT)
> >> Anyway, I ended up with a graph of Objects and
> methods which looks nice and consistent and -- clean!
> :-)
>
> I'm happy with my model. And I'm certain it would benefit
> from Core Data.
>
> > A1: A lot of beginners complain about this. A lot of
> intermediate to pros recognize that the documentation
> is far better than most platforms.
>
> That's not saying much :-)
"better than most platforms in the last 10 years", maybe.
Mac OS 7 and 8 and 9 had better docs.
Kronos, back in the 1970s, and NOS in the 1980s
had far far better docs.
So, the proper thing to do is just keep on submitting
suggestions, corrections, requests for clarifications
to the docs.
> > The trick is, you just have to take the time to
> familiarize yourself with it. Study, study, study.
> This is a very large platform with a lot of powerful
> technologies.
"Powerful" is not a word I would use in this context.
Not quite elegant, or striving to be elegant, maybe.
> It's not a toy language or API by any stretch of the
> imagination.
But Core Data seems to be.
> Finding your way around will take time.
> Learning what are clearly labeled as "advanced" technologies
> will require you to master the basics first (surprise!), so
> give it time and study.
Which "basics"? The greatest "basic" that would allow
someone to read the docs and grok how to design new
software making use of these frameworks would be the
psychotic power to reach out to the mind of the original
framework designer(s) to understand the extent and
limitation (things that seem to logically follow but
do not because he/they weren't thinking of them when
they designed this part of the frameworks) of his POV,
and the direction of development of his ideas, and
the terminology used that doesn't quite mean what it
appears to mean (not what it meant in other languages,
libraries and frameworks you've used in the past, or
in the "real world").
> > A2: All the more reason to heed the warnings and stick
> to basics. Whether Core Data is a good match for your
> project or not (more on that in a second) is largely
> irrelevant since you have already indicated (I think - the
> rambling makes this hard to say for sure) that you haven't
> read the more basic technologies upon which Core Data is
> built.
>
> No, I read the Core Data Basics chapter of the Core
> Data Programming Guide, I'm happy enough with KVC and
> KVO for now - at least my bindings between an
> NSTableView, NSArrayController and my NSArray are fine.
> So, I'm sort of OK with bindings, notifications and
> delegation, although not thoroughly immersed in the
> mind set. Yet. So, according to the recommended
> learning path, the next step would be going through
> the tutorial (which it later says, is NOT how you do
> things...)
>
> > Therefore, your first app should use the most basic
> methods. Build your data structures with dictionaries,
> arrays, and NSCoder-compliant custom objects as you wish ...
> then write the main container to a file. There's your
> document format. Start with the basics, then move on
> to the voodoo.
But I've already done the object-relational diagramming
of a major military logistics data warehouse (rat's nest,
really), a vehicle fleet management system and other
toys, and taught the techniques to others. After that,
what can seem like voodoo in far simpler graphs of data
in this thing that's not even tied to one full-featured
relational data-base? It should be a walk in the park,
a mere application of well-known principles. Only it's
not. Why not?
I'd advise reading the docs at least 3 times, and maybe
the Objective-C 1.0 and 2.0 docs (the best of the whole
lot, IMO) a couple times each.
Typically, a student is expected to retain maybe 15% of
what he reads the first time from a text book. In the
past, I've tended to retain maybe 50% from text books
and reference manuals. A good teacher answering just
the right questions as they arise can bring that up
rapidly. A second pass through documents written from
another POV, by another author, with different holes in
his presentation is also helpful. With that good
mentor who's BTDT, a bright industrious study group,
I'd be up to the 98% neighborhood before a 2nd pass
(at which point what I had for breakfast becomes a more
important factor). The OS X docs bring me down to maybe
5%-10% for a first run-through. By the time I've read
a set of them 3 times, I'm finally getting up to my
accustomed first-pass 50% or so. And, as someone noted,
there are a lot of docs, so it often happens that
between passes one or two revisions have been issued
and it's time to start over.
In Cyber days and VAX days and DG days and SGI Iris days,
I'd be up to about 85% by the 2nd pass and have
implemented the features into a couple releases. On OS
7 I'd be trying to implement features on the 2nd pass,
but be making mistakes because of ignorance of the full
context, and be needing to make a third pass to fix
bugs. On OS X, by the 3rd pass I'm just getting up the
courage to try something beyond the super-simplistic
tutorial sample code, because now a lot of these things
are not incremental; they're all or nothing. If you
don't have every duck lined up just right, it doesn't
just give not exactly the desired result, it melts
down, locks up, or crashes.
I have to agree with the OP. Don't jump into Core
Data. Use Dictionaries, try to conscientiously make
your accessors key-value compliant. Dot notation is
a nice short-hand, but you're just as well off using
the accessors conscientiously for a while.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden