Re: General MVC and ownership question

FROM : Graham
DATE : Tue Mar 04 23:59:37 2008

Thanks for picking up the ball on this one Jens, much appreciated.

I had more or less come to the same conclusion about having one 
controller per view, with the data model owning the controllers.

My actual situation is that the "data model" is in reality a vector 
drawing stack with layers, objects, groups of objects, etc. laid out 
on a "canvas". The "canvas" is a self-contained container object that 
could be owned by a document but is not in itself a document, though 
typically there might be a 1:1 correspondence in a typical app.

The view is there to render the contents of this drawing. There can 
be more than one view, either in different windows or in the same 
window (split view). So the "data model" includes methods to render 
itself into a nominated view on demand. Similarly, when something 
changes state in the drawing, the relevant areas of the views are 
flagged for update - this is why currently the data model keeps track 
of its views.

So if a controller is placed between the data model and the views, 
for this case it's not going to be doing much - just passing on the 
drawing (and user event) requests one way and the update requests the 
other. It seems to me it would be very complicated for the controller 
to handle the drawing task in the sense of asking the data model for 
its objects and then working out how to render them in the view. The 
organisation of the data model already makes this task much easier 
since the natural order that things get done provide the back-to-
front ordering of layers, objects and so on, and the objects 
themselves know how to render themselves in a variety of ways. Does 
this make any difference to the answer? I can imagine a different 
sort of view controller existing for some unusual case such as 
showing a list of objects rather than drawing them, which the current 
approach supports but in a less generic way.

The question about ownership is because the system can be built in 
two ways - either assembled by the programmer, or automatically. In 
the automatic case, simply placing the right sort of view in a nib 
creates a complete default "back end" for you - in this respect it's 
very much analogous to NSTextView that builds the editing back end to 
support the view you add to the nib. So in this latter case where the 
view builds the back end I'm keen to avoid a retain cycle since the 
normal ownership situation is partly reversed, in that there's not a 
one-way "flow" of ownership from document to data model to controller 
to view - the view has to create the data model and hence retain it.

I do need to support 10.4, so I'm not using G/C. However I'm 
comfortable with the retain/release mechanism in general.

--------
S.O.S.



On 05/03/2008, at 4:05 AM, Jens Alfke wrote:

>
> On 3 Mar '08, at 6:16 PM, Graham wrote:
>

>> The question is: would the better design be one-controller-per-
>> view, or a single controller supporting multiple views? In other 
>> words should the controller typically associate with a single view 
>> or the data model?

>
> Generally there should be a controller per view. This is because 
> the controller directly operates on the objects in the view (it has 
> IBOutlets, in Cocoa terms), and because you might have different 
> kinds of views (like list vs. icon) that require entirely different 
> controller implementations.
>

>> The follow-on question would then be: what would be considered the 
>> optimal "ownership" relationships between the various objects in 
>> the system? Do data models typically own their controllers, or 
>> should the controller(s) own the data model?

>
> There's usually a central "document" object that owns the 
> controllers, which in turn own the views. You can think of the 
> document as an über-controller.
>
> Cocoa supports this model via the NSDocument and NSWindowController 
> (and now NSViewController) classes.
>
> Have you considered using GC? I'd recommend it, if your app doesn't 
> have to support 10.4, and if it doesn't depend on 3rd party Cocoa 
> libraries that aren't GC-ready. It makes this stuff so much easier.
>
> —Jens