On Fri, Oct 17, 2008 at 03:47:04PM -0400, Kyle Sluder wrote: > On Fri, Oct 17, 2008 at 5:28 AM, Oleg Krupnov <[EMAIL PROTECTED]> wrote: > > Is there any benefit in introducing a model controller, as another > > layer of indirection between the model and the view controller? Or > > should all business logic live right in the model? In what cases > > having a separate model controller can be justified? > > Your NSDocument subclass is a model controller. Think of the model as > being strictly the data your app works with -- all the NSStrings, > NSDatas, and other value types that compose a meaningful > file/document/whatever. Your NSDocument subclass is the controller > which manages all of that data in the context of the rest of your > application. > > This manifests itself a bit subtly. For example, strictly speaking > your app's data has no way of knowing how to save itself. Your > NSDocument subclass, in its role as model controller, does. > > --Kyle Sluder
There isn't a question here, but if someone would care to comment on my architecture and perspective, I'd be interested. In my app, I'm using an external sqlite database (rather than core data for a variety of reasons). I need a rather large number of views with separate windows into the database, including both browsing and editing. So far, I've gotten one of those implemented pretty satisfactorily for both me and my user (according to reports so far). I use a master window, which is owned by MyDocument, and various other Nib based windows that are owned by custom window controllers. These are brought into being by actions of the user on the Master window. via MyDocument. The user views data or modifies it in these windows. MyDocument is responsible for finding and opening the database. MyDocument also alloc-inits various objects that do any SQL needed in response to user actions in the various windows. I've always regarded these as part of the model. But based on Kyle's remarks, I now think it would be more proper to say that they are part of a model controller layer, and only the database itself is the model. So far, all they do is SQL, hold information about the active interface, and hold array's that are shown in tables. If, there was computed data that was not part of the database itself, then the objects taking care of this would (in a purist sense) be part of the model. I guess one way to look at it would be -- The objects that could be pulled out and then run with a console based interface constitute the model. In one sense it doesn't matter what I call these unless I want to describe the architecture to a third party. In another sense, it is important to think of them in such a way as to encourage (for myself) appropriate MVC modularization as I proceed. Thanks for listening! John Velman > > 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/velman%40cox.net > > This email sent to [EMAIL PROTECTED] _______________________________________________ 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]
