This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Is MVC Pattern Overkill? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Is MVC Pattern Overkill?" Watch "Is MVC Pattern Overkill?" New topic
Author

Is MVC Pattern Overkill?

Aaron Dressin
Greenhorn

Joined: May 10, 2002
Posts: 29
Hi. I have attempted to build the client portion of the assignment using the MVC pattern. Namely, I am attempting to separate out all of the data manipulation from the view, coordinating the 2 with a controller. Is this overkill for the assignment? I have thought about just building a large gui class with the models as inner classes.
If this is not overkill, what have you found to be the best way to separate the event handling into the controller, rather than in the view? For example, a button in my view fires an action that is dependent on selected data in the view (like a table column). How do you successfully propagate the selected data into the action when the action is defined within the controller?

Is there a more "MVC" way to do this?
Thanks, Aaron


-Aaron
Jim Bedenbaugh
Ranch Hand

Joined: Nov 09, 2001
Posts: 171
I don't know about everyone else, but my Controller only contains business logic, such as you can't select the same origin and destination when searching for records, etc.
The View does one thing - paint the screen with data. Any logic related to that stays in the View.
Anytime a request is made for data in any way - search, update, etc. it goes to Model. So, if an ActionListener is added to a Find button, that action (and any find criteria) is passed over to the Model (through a Facade) and the Model handles retrieving the data.
If this is an improper way to implement, though, I sure would appreciate feed back from anyone.


Regards,
Jim
SCJP, SCJD, SCWCD, SCEA Part I
Aaron Dressin
Greenhorn

Joined: May 10, 2002
Posts: 29
I believe that all of the event handling (business logic) should be handled by the controller... not by the model. The model represents the data and should not know anything about how the view interacts with the controller to manipulate it. It should only get updated and then the controller will notify the view of a model update.
Here is my problem: My JTable is a member of the view class (ResultPanel)... not the model that backs it. When a user selects a particular row in order to book a flight, I need a way to pass the selected flight information (only known to the view) to the controller. I am handling this problem by using SwingPropertyChangeSupport, but it is becoming quite convoluted.
Whose responsibility is it to keep track of the selected row in the view's table?
Thanks,
Robin Underwood
Ranch Hand

Joined: May 01, 2002
Posts: 117
I would think it's the view's responsibility to know the selected row in its table.
My controller holds references to the views. The controller listens for the action event that occurs when the user decides to book a flight. The controller then asks the view for its selected row.
Any feedback is appreciated.
Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
Originally posted by Aaron Dressin:
I am handling this problem by using SwingPropertyChangeSupport, but it is becoming quite convoluted.

Use getSelectedRow() defined in the JTable.
Originally posted by Aaron Dressin:

Whose responsibility is it to keep track of the selected row in the view's table?

Event handler should be in the controller. In this case, the controller serves the model/controller part for your GUI. Keep the table model in the controller.
Robin Underwood
Ranch Hand

Joined: May 01, 2002
Posts: 117
I agree that the Event handler should be with the controller, but I think the TableModel is a view of the data and should be kept with the view. The Controller should pass actual data (DataInfo[]) to the view, and the view should construct the TableModel from that data. All the controller needs to know from the view is which record was selected.
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
Originally posted by Aaron Dressin:
I believe that all of the event handling (business logic) should be handled by the controller... not by the model. The model represents the data and should not know anything about how the view interacts with the controller to manipulate it. It should only get updated and then the controller will notify the view of a model update.

Since the early part of the thread seemed to be heading in the "what is the proper way to use MVC?" direction, I just wanted to add a couple of comments. I'm not saying your approach isn't valid, just that there may be another way of thinking about it.
People often get confused about the roles within MVC. Most of that stems from the fact that we get in the habit of thinking that there are three components, when that isn't what the pattern is about. The general scenario is multiple views, multiple controllers (both possibly changing in number or kind dynamically) and one model.
When you think of MVC as three components and have some coding issue, you think "where should I put this piece of code?". You debate whether the issues feels view-like, etc. Generally the result is that the controller or view end up as a dumping ground for things they shouldn't contain.
Business logic is a typical example. If you have one model, and multiple views and controllers, the answer is pretty obvious. Business logic is shared, and belongs in the model so that the model can enforce the business rules. Changing views and changing controllers doesn't change your business logic. That is the pattern. Events are not business logic, they are just a communications/notification mechanism.
For more information on MVC, I'd suggest "Pattern-Oriented Software Architecture", Buschmann et al. I've got the older one-volume book; there is now a two-volume set (not sure which volume contains MVC).


Reid - SCJP2 (April 2002)
Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
Originally posted by Robin Underwood:
The Controller should pass actual data (DataInfo[]) to the view, and the view should construct the TableModel from that data. All the controller needs to know from the view is which record was selected.

What if you migrate this application CORBA or EJB architecture and there is no DataInfo class anymore? How many classes you want change to extend the current architecture? If the view knows about the business object or any architecure specific classes, it is a bad design.
[ May 30, 2002: Message edited by: Sai Prasad ]
morten wilken
Greenhorn

Joined: May 25, 2002
Posts: 13
hi reid,
very lucid description of a topic that i too have westled with.
would you implement all calls to the db (which in my case is behind a facade) in the model?
and would you agree that the tablemodel is the model in this case (as the name implies)?
and thirdly, when i want to do a search i trigger an action in the controller. will this action call a method on the tablemodel, or would you make the model a listner on the controller?
sincerely
morten wilken
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
Well, I'm only signing up today to start on the SCJD, so I haven't seen the project. I can only speak a bit off the top of my head.
To me the most important initial architectural question is, where are the MVC components located? The view is pretty obvious; that is on the client side. What about the rest? There are multiple choices.
In EJB, the model would definitely only be on the server side. The question would more be about locating the controller. At least part of it would be on the client (i.e. the web container) side. There might be a bit of it on the server side, e.g. if session beans are hiding entity beans or queueing requests via JMS.
For an RMI project I'm not sure yet where the balance is. Obviously some of the controller is on the client side; I think probably all of the controller. What I'm not sure of is the model; does the model have a bit of a footprint in the client?
I don't have any answers yet to your table questions; Swing is a new experience for me. I've been doing servlet and EJB stuff for a few years, but I'm taking the SCJD to motivate me to work with the Java technologies I otherwise wouldn't touch.
Re: facade and calls to the db; I don't know your code, but I would assume that you are using a facade to simplify the interface to the model. If that is the case, then anything the facade would invoke sounds like it would be part of the model. The "where does the code really live" question can get a little fuzzy when you start entering the realm of pattern composition.
Robin Underwood
Ranch Hand

Joined: May 01, 2002
Posts: 117
Sai,
I thought about what you said and I changed my mind. I agree that the Table Model should go in the Controller. I'm going to pass a ready-to-go Table Model to my view so it won't need to know anything about DataInfo or FieldInfo.
Thanks for your input!
Robin
morten wilken
Greenhorn

Joined: May 25, 2002
Posts: 13
just to continue the discussion,
in my design the JTable is the view, the controller is the class where i implement the inner listener classes.
the model is the TableModel i have implemented that wraps a DataInfo[].
my question is: how does the controller change the model? do i put businesslogic methods (ie. bookflight) in the tablemodel?
today i have a businessfacade with the methods, so i could also let the controller call by facade and let the tablemodel 'observe' (with Observer) the facade. im a bit puzzled here....
what do you think?
sincerely
morten wilken
Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
I would keep the table model reusable. So I wouldn't use any flight or architecure specific objects in the table model. You can use Object[][] to communicate between the controller and the table model.
Eduard Jodas
Ranch Hand

Joined: May 14, 2002
Posts: 80
I wouldn't let the table model know about DataInfo, the same as I never let my GUI know about JDBC ResultSets. That's something the Facade class should deal with.
Troy Travis
Greenhorn

Joined: Jun 15, 2009
Posts: 3
I know this is an old thread, but here is how I am implementing MVC.

Since I have a client-remote, client-local, and server, I have 3 controllers with an appropriately designed hierarchy.
Views contain no business logic aside from what is needed to manipulate the GUI: the views are merely the components that are displayed.
The models back the views. Whatever data I need to propagate around the client is stored in the model. So, if any text field is updated or row is selected, or if a result set is returned from a search, these values are stored in the appropriate model.

All views instantiate their own models, but not all views have an associated model. For instance, I have a status bar whose displayable data is pushed to it from various view and controller events.

Each view and model is registered on the controller.
When an event occurs from a view, the event with appropriate data is sent to the controller and the controller notifies each registered model via reflection. If, a model is interested in listening to a particular event from a view it will be invoked. Once the model changes, all other views that are interested in the change will update accordingly.

For example, when I press 'search' on my search view, it invokes the controller. The controller, since it contains all the business components, will query the database (locally or remotely.) Upon returning with the results a Vector<E> is sent to the appropriate model, the model then passes the data to the search results view and updates the table: the model also passes the results to the status bar view and it updates it's status for number of records returned.

The controller, can also initiate an update to view components when it sees fit. If for example the network is inaccessible, it will push this information to the status bar, and disable the CSR main screen for all user inputs.

Hopes this helps someone.
 
jQuery in Action, 2nd edition
 
subject: Is MVC Pattern Overkill?
 
Similar Threads
writing good GUI code
Who should interact with the rest of the system in a MVC design? Model or Controller?
Swing
GUI, actions and controller
Question on class design for DataClient and Client