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: WhiteContainer <email@hidden>
- Date: Mon, 20 Mar 2006 11:33:34 +0100
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 :
- On one hand he can play with the interface directly via outlets/
actions. He is also the boss of other controllers (like NSArray/Tree/
ObjectControllers), in the sense he delivers to them a
managedObjectContext to use and a managedObjectModel to refer.
- On the other hand he can play with datas because he owns the
managedObjectModel, the "main" managedObjectContext and can configure
a persistentStoreCoordinator.
> 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.
> When is it useful to create another MOC ?
- In another thread
- When using another NSPersistentStore
- I would add : maybe in a class method ? 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]] ?
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 ?
> 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
_______________________________________________
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