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.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
