• Post Reply Bookmark Topic Watch Topic
  • New Topic

Where is the controller in MVC?  RSS feed

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
(I'm a little past Java newbie, I hope, but far from advanced.)
I'm convinced: Model/View/Controller is a Big Idea, turning
up everywhere from event handlers to J2EE. My problem is that
although the model and the view are usually obvious, the location
and responsibility of the controller seem much more fuzzy in
a lot of cases.
Take the diagram on p 361 of Head First Java. Perhaps I'm
too tired, and that's not supposed to be an application of the
MVC idea, but assuming it is . . . what's what? The Event
object must be the Model, but what roles are the Listener
and Source playing, in MVC terms?
TIA,
Dan McCracken
 
author
Ranch Hand
Posts: 201
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've always thought informally of the controller as the "glueware" that keeps the model and view in synch; a change to the model is reflected in the view, and vice versa. If you accept this interpretation, then one could argue that the event handling mechanism of Java (along with the actual mechanism of the JVM itself) serves as the controller. Your role in writing the controller, then, amounts to deciding which events you are going to pay attention to, then designing/registering the appropriate listeners.

(To allow the view to listen to the model, explore PropertyChangeListeners ...).

Regards,

Jacquie
 
Daniel McCracken
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Jacquie.
I've used the "glueware" description, too, but the boundaries
are sometimes hard to pin down. In a high-level picture of the
J2EE architecture, well, sure, the databasse and the business
logic are the Model, the browser and maybe the Web server are
the View, and the Controller is all the stuff that holds things
together, with the Model and the View never talking to each other
directly.
But . . . in your description Java event handling it sounds
like everything is the Controller. What is the Model and what is
the View?
With an app that uses the Observable/Observer pattern, things
are fairly clear. With event handling it's less clear. Maybe this
isn't a great first example the the MVC idea?
Thanks again.
Dan McCracken
 
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of my favorite phrases from some training long ago was the controller's responsibility to "interpret user gestures" into some action. It says, "The user clicked that button ... he must want this action!" The button never knows what action it might trigger, and the action never knows what widget or gesture triggered it. "Glue" is a good way to think about the controller, but it's also "insulation" to keep view stuff and model stuff from touching each other.
 
Daniel McCracken
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks. This helps too.
So. Suppose we're talking about a button; when the user
clicks it, something visible happens (a color changes, a dialog
pops up, whatever). Then I guess it's clear:
Model = the button. The button holds its state.
View = whatever result the user sees.
Controller = the registration/callback coding that
listens for button events and takes whatever action was
specified.
Unless I'm totally lost, which has happened, this is
clear enough, and students will buy it. Thanks.
Ummm, but what if the result of the user's click is not
visible, but only changes the value of some variable, say.
Now what is the View? The fact that the button changes
shape/color while depressed?
I am not questioning the importance of the MVC pattern.
But I'm a teacher, and I have to explain this stuff . . .
Dan McCracken
 
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Daniel McCracken:
Model = the button. The button holds its state.


No, the button is part of the view. The button notifies the controller when it got clicked. The controller then decides what to do - it might either activate some business value in the model, and/or activate some action in the view (such as popping up a dialog).

Ummm, but what if the result of the user's click is not
visible, but only changes the value of some variable, say.
Now what is the View? The fact that the button changes
shape/color while depressed?


Yes, that's part of the view. Besides that, a user action might not show up in the view at all (which might be a problem to the user, though, because he doesn't get any feedback on wether the desired action actually took place).

I am not questioning the importance of the MVC pattern.


Well, the MVC certainly is important, but it's not necessarily appropriate in all cases. There are alternative patterns, such as Model View Presenter (which is more along the lines of the Presenter really sitting between Model and View), Document View and probably others.

The intention of the MVC pattern is to decouple form of input (Controller) from form of output (View) from business logic (Model).

So, for example, if you just want to change your form of input from mouse gestures to speak recognition, you just exchange the Controller and reuse the View and Model, and everything still should work (ideally at least).
 
Daniel McCracken
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, thanks for this too.
I'm getting the feeling that isolating a button that does some really simple action--user clicks and get a popup, say--disconnected from anything else in the app, is not an ideal example for motivating the value of the MVC pattern.
I've got a supergood example from Joe Bergin of Pace Univ. An Observable Model holds a temperature. Observers register with it and are notified when anything changes the temperature. Each Observer then puts up its favorite way of displaying the temp. Not trivial for newbies, actually, but it has all the pieces and makes a good teaching tool.
And with Web-based apps, the MVC pieces are usually quite clear, although the exact boundaries of the Controller can still be somewhat murky.
I'm of course listening for any more elucidations, but I'm about ready to say thanks to all, and carry on.
Dan McCracken
-------
Author of lots of stuff, none exactly relevant here.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I like your temperature model example. You didn't say exactly, but I bet you're picturing the view as the observer. The model would be built so that any number of kind of views could observe it.

Now if your view has some buttons to turn on heat or cooling things get even more interesting. The view tells the controller "button 1 pushed!", the controller tells the model to turn on the heat, and the model tells anybody who is interested that the temp has changed.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!