Re: MVC, DBA, CoreData (was: CoreData : fundamental (or not) questions)
Re: MVC, DBA, CoreData (was: CoreData : fundamental (or not) questions)
- Subject: Re: MVC, DBA, CoreData (was: CoreData : fundamental (or not) questions)
- From: mmalcolm crawford <email@hidden>
- Date: Mon, 20 Mar 2006 09:02:04 -0800
On Mar 20, 2006, at 2:33 AM, WhiteContainer wrote:
So...I think my questions were really fundamental...:-)
Unfortunately the first sentence here suggests you don't yet fully
understand MVC.
mmalc
Let's see...and let's resume now and maybe add some ideas :
> NSPersistentDocument is the File's Owner, his boss is
NSDocumentController.
He is a kind of "super controller" because :
Why introduce new terminology? They're both controllers.
> NSManagedObjetContext is also a controller but maybe a new type
of controller, which plays in a kind of "MDC" paradigm : Model-
DeepDatas-Controller. He manages relationships between deep datas
(persistentStore) and their corresponding objects manipulated in
the code.
The context is a model-controller.
> When is it useful to create another MOC ?
- In another thread
- When using another NSPersistentStore
No. As the documentation states, a role of the persistent store
coordinator is to present a facade to the context(s) of one or more
persistent stores aggregated into one store. As my earlier response
stated, "You can use an additional context or contexts whenever you
need to managed a set of edits that is disjoint from those in
whatever other context you are using."
- I would add : maybe in a class method ?
No. In a class method you're more likely to pass in the context to
use...
So maybe in any place where [self managedObjectContext] returns nil
or will not give an access to all datas (many stores, custom
stores...) ? Is it better to create a new one than retrieving the
main moc with this path : [[[NSDocumentController
sharedDocumentController] currentDocument] managedObjectContext]] ?
No.
Personally in this situation I would pass in a reference to the MOC
Marcus S. Zarra
I do not see what you mean by "pass in a reference to the MOC",
maybe MOC should be read MOM ?
No, he means MOC -- compare, for example, the NSEntityDescription
method insertNewObjectForEntityForName:inManagedObjectContext:.
> Controller selection in MO :
There should be no reason for the Department object to access the
controller's selection.
mmalc
I agree but look at the following source code in the iClass example
from Xcode (Student.m).
It is an add: method based on the user's selection in a tableView
(to add some objects in a to-many relationship).
So a Department.m could have methods to set, get, calculate, manage
his underlying datas but also its own particular methods to add:
remove: insert: its datas...And to add objects in a relationship,
one of the most user-friendly way, is an add: based on the user's
selection in a table.
#import "Student.h"
#import "Course.h"
@implementation Student
(...)
- (void)addCourse:(NSArray *)aCourse {
Course *realCourse = [aCourse objectAtIndex: 0];
[[self mutableSetValueForKey: @"courses"] addObject: realCourse];
}
(...)
@end
This is a generic method to add an object to a relationship -- there
is nothing specific to a table view here.
mmalc
_______________________________________________
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