General MVC and ownership question

  • I have an object embodying a data model. In a document-based app,
    there would be one of these per doc. There can be one or more views
    on this data (for example a split view of it). Currently I don't have
    a controller between the two - the view is pretty specific so it
    implements the controller-like methods directly.

    However I'm considering putting in a controller between the two,
    mostly for the sake of MVC "purity" as it's unclear what this object
    would do except relay messages between the two and reduce performance
    (slightly). But let's say it's worth doing for some good reason yet
    to be determined.

    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?

    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? What about ownership of the views?
    Should this be in addition to the ownership of the views by the
    window they live in? The point is to avoid retain cycles between the
    various parts.

    So a final question would be: if there are weak references to objects
    (as there are bound to be in various places) but these are a list of
    objects, what's a good way to handle this? NSArray obviously retains
    its elements so it seems just using an array would be unsuitable
    here. What solutions do others use for the "list of weak references"
    problem?

    Any insight into this would be very welcome,

    --------
    S.O.S.
  • 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
  • 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
previous month march 2008 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Go to today