File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes MVC questions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "MVC questions" Watch "MVC questions" New topic

MVC questions

Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
OK, now that is quieter here and getting rather noisy in JIG (beginner), I figured I'd hide out here for a while and bother you guys. Hope dirk doesn't catch me loafing.
OK, I have set myself up with a project, not for work or school or anything that has to be done, it is just for my own practice and experience. I'm going to have GUI for users to interact with the project and want to use the MVC architecture for it. I've done some reading up on it but am still a bit fuzzy so I have a few questions:
Concerning views and controllers, I'm not sure I understand where to draw the line between them I know it isn't always that clear but I think it should be little clearer then I am now.
The GUI will have several panes and other popup windows for the user to interact with. Some of them will contain data while others will be related to the program (help screens, user preferences, etc). Will all of the data views have an associated controller?
All the controller does is take user input in the view and send it to the model correct? I guess my question then, is why have it at all if that is all it does? Why not just have the code in the view itself? In most cases isn't it just a method call to the model or sending an event to the model? And what about when the interaction is with a button that is displayed on a view, does the view send the event to the controller who sends it to the model?
That leads me to my second question, in many cases the user interaction will be a simple button click. My thoughts are to create a bunch of events that can be sent by the controllers/views to the model who has listeners waiting for these events, this avoids me having to code method calls into the contoller/views so the model can change later without changing anything else. Is that the 'accepted' or 'recommeneded' way of doing things?
Lastly, for now anyway, I want to do this project in a few phases/stages to get the hang of adding functionality to things. I want to set up a core application that has the base functionality in it then add to it later. My thoughts on adding are that using the MVC when I create a new thing to add to it all I'll have to do is add the menu/toolbar items to use it and then, when that view is created, it'll 'register' itself with the controller so it can made aware of any changes in the data that effect it.
I used the MVC once in school but it was in an MFC application which did most of the work for me so this is my first time trying to do it all myself. Any help or comments would be cool, or a link to good site with a decent explanation of the MVC would be great, I've read a few but still had these questions.
I'm to the point now where I am going to be starting to rough out the objects and some of the state and transition diagrams for this and wanted to make sure I'm on the right track before I get too far.
Thanks again everyone (back to my own neck of the woods now)...

Junilu Lacar

Joined: Feb 26, 2001
Posts: 6529

Good questions, Dave. I had these doubts myself from time to time. I had started to write a reply but after reviewing it, I felt like I'd only confuse the issue even more for you so I'm going to defer for now. (Besides, I'm still recovering from the book giveaway :roll: ) I'll get back to you in a bit.
Just wanted to let you know that you're not being ignored...
Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
Cool Junilu, take your time.
Any insight you can give would be really appreciated, even it is just some links.
Anyone else can feel free to jump in here too
sunil g nair

Joined: Jun 03, 2002
Posts: 14
There are a number of ways of doing things many of which are wrong and many of which have varying levels of correctness.
As to why we use a controller, well, that depends a lot on what the controller does.
Like for example a simple example will be if the controller makes use of a command pattern.
In this scenario the controller may be smart Servlet which gets the user action, looks up the corresponding Command for that action from a property file, instantiate and execute that command, which in turn may call a series of sub-commands (re-usable).
The command will then let the smart-Servlet know which page to direct the request to.
The struts framework is an advanced framework designed on this basic principle.
I may not have done a good job of explaining what I have in mind, but the design pattern link within Java soft should be helpful.
sim sim
Ranch Hand

Joined: Jun 05, 2002
Posts: 55
Hi Dave,
Extending Sunils reply with an example,
let us say that I have a page with 4 choices and a submit button. Depending on the options selected the submit button can perform different action. To achive this, if I write the code in the view, it would be an ugly looking, hard to manage, disturbing the view layer code. The complexity increses with increse in user options.
Instead it would be nice if I have a controller which takes the input, decides and performs the actions on behalf of the view.
I hope this gives an answer to your question.
But again as said, there are many ways to achive something
Sim Sim.
Hari babu
Ranch Hand

Joined: Jun 25, 2001
Posts: 208
Here is what i feel. Correct me if iam wrong.
Usually we avoid mixing the controller and the view code, because today we may have one kind of view (HTML/JSP) tommorrow we may have diffrent view (WML). Tommorrow when the view changes or view gets added, we need not change the controller,If the controller is in single place, since we can re-use the same control for user actions.

Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
Thanks for the replys guys
Just to clarify things, using Sim's example of a page with 4 choices and a submit button.
The page itself with the submit button, the checkboxes, textfields, radio buttons or whatever they are for the user choices would all be part of the view.
When clicked, the button would just call a method in the controller class and send it the values that the user picked correct? Or is it better to have it generate an event that goes to the controller, at that point the controller gets the required data from the view?
Thanks again for your input, any thoughts on the other parts of my post?
Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
Another thought I had that I'd like someone to let me know if I'm the right track...
Another purpose in having the view and the controller separate is that the controller can expose a set of methods or register specific event listeners. When they are called/invoked the controller knows what to do to the view or the model in response to whatever listener or event handler was activated. That way changes to the controller will not effect the view or the other classes that us the controller so long as the controllers methods and/or event handlers remain the same.
This is better than putting it all in the view because then the entire view might have to change in response to a code change and also because the same controller might be used for multiple views so it is better to keep it separate instead of duplicating code.
Am I on the right track?
thanks everyone...
[ June 14, 2002: Message edited by: Dave Vick ]
Frank Zheng
Ranch Hand

Joined: Jun 12, 2001
Posts: 76
I have similiar confustion too. Is it necessary to clearly separate the listeners into the controller?
Some developers claimed that put anonemous listeners in the view is making more sense? Is this true?
More light, please.
[ June 14, 2002: Message edited by: Frank Zheng ]

Sun Certified Java Programmer
Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
Hey Frank
I had kind of the same questions and the best answer I can come up with is if it is going to be a relatively small handler and only used by one view then it could go as an annonymous class in the view itself. If, on the other hand, it is large or going to be used by multiple views or controllers, then it should go into a view.
Like I said though, I am fairly new to this type of project so... anyone else??...
It is sorta covered in the JavaRanch Style Guide.
subject: MVC questions
It's not a secret anymore!