Model view controller confusion
I'm a beginner at this stuff... I've been learning about the model view controller idea, and it seems great, except that I'm very confused by the different accounts of the responsibilities of a controller...
3 different interpretations I found say that a controller's responsibility is the...
1) Reaction to user actions / input devices
2) Definition of capabilities (which are passed to the view so that a view can be created appropriately)
3) Mediation between View and Model (translates events to actions on model and updates view to reflect changes to model)
I'm confused... is a controller supposed to do all of these things at once? It seems like it's doing a lot of things
I'm also thoroughly confused on the view controller relationship (mostly because I don't have a good grasp on what a controller is). Is the view responsible for knowing the capabilities of the system?
For example:
Suppose we created a Jukebox Application.
Should the view know (without being told) what buttons it should create? (Play, Random, Stop, etc...)
or is it the controller's responsibility to let the view know what buttons it should create?
Thanks,
Alvin
[1235 byte] By [
alvinraja] at [2007-9-30 0:48:45]
Here's a pretty good place to learn... http://java.sun.com/products/jfc/tsc/articles/architecture/...and this gives kind of readers-digest view... http://java.sun.com/blueprints/patterns/MVC-detailed.html
The view knows automatically what buttons to create as the view is the presenter of information. So I would say yes, it knows what buttons to create.
The model is just a collection of data. A data holder if you will. Only processing it does is with respect to serialization or some form of storage and loading.
The controller translates the models data into something the view can understand.
As an example, if your model stores x,y,width, height in a database. You view wants to display a box. The controller would convert from x,y,width,height into a Rectangle and pass that rectangle to the view.
Also if pushing a button causes the data to change in some way, the controller would respond to that event from the view, and modify the model apprpriately.
I disagree with dnoyeB's definition.
To quote the Swing whitepaper quoted earlier:
* A model that represents the data for the application.
* The view that is the visual representation of that data.
* A controller that takes user input on the view and translates that to changes in the model.
The view reads data from the model and presents it in the way the particular view implementation presents data. The controller isn't involved in this direcly.
The model can be, and often is, more than just a data store. It contains the application logic, which means it processes the data, e.g. contains algorithms etc, is in charge of communicating with other applications, systems and back-end processes. If you have a client/server application, think of the server as the model. This is especially true when you have thin clients. (For fat client systems, part of the model is copied in the client.)
The view and the controller, in contrast to the model, are essentially stupid - they're just a user interface.
How the view and the controller are to be separated isn't a clear-cut thing, in the end it depends on the application. In Swing for instance, they decided to join the two into a single entity:
"We quickly discovered that this split didn't work well in practical terms because the view and controller parts of a component required a tight coupling (for example, it was very difficult to write a generic controller that didn't know specifics about the view). So we collapsed these two entities into a single UI (user-interface) object"
On the other hand, in a strategy game I'm writing, I have a clear-cut "view" component that renders the map on the screen, and a fully decoupled "controller" component that takes all mouse input generated on the view's screen area and acts upon it (sends commands to the view to scroll/zoom, or sends commands to the model to move a unit (in which case the model will notify the view that it needs to update the unit)). The view has only rendering logic and cares nothing for user input. The controller is configured through config files - what left/right mouse button should do etc. This way the model and the view implementations can be exchanged and modified independently of each other, within the boundaries of their well-defined interfaces to each other.
R
/ Chris
Uhh you disagree on which point?
I said a model would store the data in a database, how is that different from your statement about communicating with other applications or back-end processes, or with a server? Its not.
However, the controller most certainly converts models data into that which the view can understand. If it does not, then you have no MVC, you have MV. Perhaps this is why you couldn't split them apart fully.
Seperation between the view and the controller IS clear cut. No reference to the model should appear in the view al all. No reference to the view should appear in the model at all. Not even interfaces they implement. Without a controller, this is impossible.
Hi,
There are several interpretations as how the MVC pattern must be implemented (is the view an observer of the data in a publisher / subscriber fashion, are they completly unrelated, etc). As a way to understand it, you can use the following guidelines:
1. The model stores your data. If it's very, very simple it can be a single class. Otherwise I can be all the entities you require for your problem (Martin Fowler suggests using one single "Model" class to bind them all. I found this approach useful). The model has the data and the operations that you can do with that data. It knows *nothing* about the outter world (a simple example is a class with a Name / Surname / Address and its geter / setters)
2. The view knows how to render data in the screen. This is his main priority. Also, it passes the inputs from the user to the controller. It doesn't do anything but pass the event to the propper controller method.
3. The controller is a dispatcher. It receives the input from the view and notifies whatever class needs to be called. There are two tricks you can use here to know you have a clean controller: think that you are using the controller from a console base systems. All its methods must be called from the command line (of course, with the info required). The second: if your controller methods have more than 10 lines, they are probably doing way too much. It's a dispatcher, it doesn't contain any application data logic.
HTH,
- Juan
dnoyeB:
In regard of the model, you said that "Only processing it does is with respect to serialization or some form of storage and loading." This is false, as I explained in my post.
The controller certainly does no data conversion. If you take a look at the conventional MVC diagram, you'll see that the model and the view interact directly. This is a good thing unless you want the implementation details of the model and the view to spill over into the controller... The controller is essentially a user input definer (as in defining how user does input) and handler/dispatcher (as in reacting to the user's input).
This is not to say that one may want a translation layer between the model and the view to acheive a looser coupling, I use such components myself sometimes. But this mustn't be confused with the controller, since user input has nothing to do with this.
Also, it is usually bad design for the model to be dependent on the view. A model may have one, several, or no views active at any particular time (in the general design case). The views may be very different (e.g. 2D or 3D). It should be up to the view to adapt to the model's data interface, not the other way around. In Java, this association is usually implemented using events and listeners. The views sign up as listeners on state changes in the model, which yields a very clean design.
R
/ Chris
I like having view, controller, and model in separate packages (if the UI is Swing/AWT). Even better, I like having no connection between the model and view packages. The controller is the only package that knows about the other two, and the relationships are not bidirectional.
I have the controller instantiate the view.The controller is the listener, and registers that fact with the UI. It listens for events from the UI, responds by updating the model, and and then changes the view. Neither the model nor the view have to know about each other OR the controller. - MOD
> dnoyeB:
> In regard of the model, you said that "Only processing
> it does is with respect to serialization or some form
> of storage and loading." This is false, as I
> explained in my post.
>
its not false, and is the same thing as you said. file storage is not the only form of serialization. communication with a database is also serialization...
> Also, it is usually bad design for the model to be
> dependent on the view. A model may have one, several,
> or no views active at any particular time (in the
> general design case). The views may be very different
> (e.g. 2D or 3D). It should be up to the view to adapt
> to the model's data interface, not the other way
> around. In Java, this association is usually
> implemented using events and listeners. The views
> sign up as listeners on state changes in the model,
> which yields a very clean design.
>
How can you say
"it is usually bad design for the model to be dependent on the view"
Then say
" It should be up to the view to adapt to the model's data interface, not the other way around. "
This is MVC, not MV. If you want to do MV, that is fine, but its not MVC.
dnoyeB, your two qoutes are saying essentially the same thing, so what exactly is your problem with them?
Besides, it would be interesting to see an argument on your part as to *why* the controller should be an intermediary layer between the model and the view, essentially yielding a multi-layer solution instead of the conventional "triangle" MVC design?
R
/ Chris
