Re: Design Question for Model and View
Jason Cavett wrote:
The strikes me more as a pure MVC solution due to
the fact that the model is doing everything and the view is *only*
being a view for the model. (AKA - The view will have no logic
whatsoever.)
For example, in "non-pure" MVC...
The view asks the user, "This project is not saved. Do you want to
save?"
No - that is not MVC. How would the view know the project is not saved? It
has to ask the model if the project is saved.
The user selects an answer.
The view checks the answer and based on the answer tells the model
what to do.
In "pure" MVC.
The view asks the user, "This project is not saved. Do you want to
save?"
No - that is not MVC. How would the view know the project is not saved? It
has to ask the model if the project is saved.
The user selects and answer.
The view sends the answer to the model.
The model checks the answer and, based on the answer, performs the
action.
What you call "pure" MVC is less conformant to the MVC pattern. In what you
call "pure" the model interprets the answer, but the answer is a view
artifact. Having the view interpret the answer and direct the model is more
"pure".
I'm guessing a separate controller may be applicable here, but I don't
see a *huge* need for a separate controller. As I stated in my post
below - I'm always confused how the controller fits into everything.
I've researched a bit online, but other people seem to have different
thoughts on how it fits in as well.
The controller receives the request directly, parses it enough to determine
which logic applies, sends the request data (possibly parsed first) to the
appropriate model logic. Based on a result condition from the model, it
selects the next view.
Another term for the controller is the "dispatcher". Think of a taxi service
- the dispatcher doesn't drive the cars, they select the next, nearest
available service component (taxi) to handle the request. To have the view
(telephone) interact directly with individual taxis would be horridly
inefficient - you could have dozens of calls go to one taxi and none to any of
the others.
The dispatcher needs some knowledge of the model (available vehicles) to
determine that you are asking for a limousine that seats eight, not a Mini
that seats barely two.
If you send directly to a "logic" component you lose flexibility in the face
of view evolution. (Taxi service via internet - now every cab needs a 'net
connection, unless you have a dispatcher.)
There is no "pure" version of any of these implementations. There will always
be boundary layers between model and controller and between view and
controller. The controller will do some things that arguably belong in the
view, and it will do some things that arguably belong in the model. It's part
of what makes programming more an art than a science.
--
Lew