Re: CoreData : fundamental (or not) questions
Re: CoreData : fundamental (or not) questions
- Subject: Re: CoreData : fundamental (or not) questions
- From: Joshua Scott Emmons <email@hidden>
- Date: Sun, 19 Mar 2006 13:35:29 -0600
On Mar 19, 2006, at 11:39 AM, WhiteContainer wrote:
1- Ok, that confirms my opinion. Maybe in a sheet or in another
window (where user can edit and create mo) should we use another moc ?
I suppose you could... I think this might be another design thing,
though. As I normally think of it, your average Document-based app
works something like this:
+-------+
|window | \ ---------------- KVO ------------------
+-------+ \ / \
+-------+ \ +------------+ +------------+ +-----+
| panel | ---- | controller | <--MOC-- | NSDocument | <--MOC-- |Store|
+-------+ / +------------+ +------------+ +-----+
+-------+ /
| sheet | /
+-------+
So: NSDocument represents the Model (which is actually implemented
with CoreData) via its managedObjectContext. The Controller is passed
this MOC. It uses the MOC to send messages to to the Model. The
controller is also responsible for maintaining all the views
(windows, views, panels, whatever). If the user wants to (say) create
an MO by clicking on a panel or a sheet, that click is sent to the
Controller for handling. The Controller has a reference to the MOC,
and can send it a message to to create a new MO. The Controller is
also KVO-ing the Store. As soon as the store actually creates the MO,
the Controller is sent a message. It updates the panel or window or
whatever when it processes this message.
The important thing to notice about the above is that it's the
Controller that has to have access to the MOC, not the window, panel,
or any other View. You could have multiple Controllers, if you want.
But as long as the View they are controlling has anything to do with
your Object Store, they should have a reference to MOC. And for the
sake of greatly simplifying things, there's no reason that reference
should not be the same one returned by [NSDocument
managedObjectContext].
2- Yes, I meant subclass of mo.
For sure, but if you want to access the moc in a + classMethod (of
i.e Department.m), [self managedObjectContext] does not work,
because "self" (the class) is not a mo.
Yes, that does complicate things because class methods can be called
even when there is no instance of an object and even if the object is
not a part of a managed store (which means it wouldn't have a MOC
anyway). I know nothing about your code, and I know I've been
preaching MVC for a while now. But as a helpful tip: whenever I come
across things like this in my apps where I have to go out of my way
to do something seemingly simple, it's usually because there would be
a simpler and more elegant place for me to put my code. In this case,
for example, maybe it would be more fitting to implement the
functionality you are considering in the Controller (as it already
has a MOC)? Or maybe it would be better to implement it in your
NSManagedObject's instance's -awakeFromFetch or -awakeFromInsert,
where you're pretty much guaranteed that the MO is now a part of the
managed store and thus has a MOC to return to you? Just a thought.
Ok for the MVC, but if you want to access to the selectedObject of
a controller inside the code of your Department.m
Assuming that Department part of your Core Data object graph, the
answer is "you don't". In MVC terms, the Model is only concerned with
what data is stored and what the relationship between the data is.
Concepts like "selection" only happen at runtime after the user
tinkers with your app. The Model only needs to know about things that
need to be saved, and selection doesn't qualify. That's why
selectedObject is in your Controller, and why it's so difficult to
get to it from your Model.
If the act of the user selecting something changes your data in some
way, you should have your Controller react to a change in selection
by modifying your Model via the Controller's instance of the MOC.
That is, the Controller should tell the Model what to do. The Model
should not ask the Controller what to do.
As you can see my problem is mainly communications-based ... I
understand ... but it is another story to find the good way to make
all of these things playing together.
I guarantee you it was the same with every other person on this list
at one time or another. Cocoa (in general) and Core Data (in
particular) do a LOT of work for you. But they do that work using
very specific patterns that are not always immediately obvious. If
you unknowingly work against those patterns, everything becomes an
uphill battle.
The good news is that the patterns Cocoa and Core Data use are based
on what millions of man-hours have determined to be the "Best Way" to
do things, and are flexible enough to encompas even the most bazaar
application concepts. The trick is recognizing how your app fits the
patterns.
Reading a Gang of Four book on design patterns may give you a leg up
here. Or obsessively reading this mailing list and various design
pattern wikis online. http://tinyurl.com/opnvh is helpful, though not
as helpful as it could be. Currently my favorite book on the subject
is Head First Design Patterns (ISBN: 0596007124). It doesn't talk
specifically about Cocoa, and most of the examples are in Java. But
you approach it with an open mind, you'll start to see how a lot of
the pieces come together.
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