Re: [MVC Design] Model Controller Rationale?
Re: [MVC Design] Model Controller Rationale?
- Subject: Re: [MVC Design] Model Controller Rationale?
- From: John Velman <email@hidden>
- Date: Thu, 23 Oct 2008 16:59:29 -0700
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@hidden> 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 (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden