Java: Worries about my implementation of MVC in a GUI Application

Question

This is a question I have in regards to my implementation of the MVC design paradigm that I came up with. The MVC type I am using is where everything must go through the controller. No communication happens between the model and the View. This is what I saw apple doing when I played with some iPhone stuff so I wanted to work through it, even though I had to put my iPhone stuff on hold.

So the issue I am having is I am seeing a lot of what I see as dirty, unnecessary looking code due to me trying to maintain this paradigm and because of this I have a feeling I am going about this quite incorrectly. So I thought I would seek some advice from you guys, who have much more experience in this sort of thing.

Here is an example of code that just gets handed from class to class just so that it passes through the controller:

I have a ViewController JFrame that holds all of the panels for my GUI. It also contains the next and previous buttons required for navigating through them.

So.. This is going to look scary but it is just a LOT of repeated code, I am going to put these in order of how they are called.

NextButton is pressed:

(ViewManager.java):

private void nextButtonActionPerformed(java.awt.event.ActionEvent evt) { controller.nextPanelRequested(); } 

(Controller.java):

public void nextPanelRequested() { model.readPanel(); // Only following this chain ... } 

(Model.java):

public void readPanel() { ... //LOGIC TO DETERMINE WHICH PANEL WE ARE ON, WHICH DETERMINES WHICH 'FETCH' TO USE: case PANELX: controller.fetchPanelInfo(panelList[PANELX]); break; .... } 

(Controller.java [Again]):

public void fetchPanelInfo(Panel currentPanel) { ... else if (currentPanel.equals(Panel.PANELX)) { viewManager.getPANELXInfo(); } } 

(ViewManager.java [Again]):

public void getPANELXInfo() { // This calls down to a specific JPanel and gets it to collect input and send. panelX.collectAndSendPanelInfo(); } 

(PanelX.java):

public void collectAndSendPanelInfo() { viewManager.sendPanelXData(double1, double2, double3, ..., double 15); } 

(ViewManager.java [Again x2]):

public void sentPanelXData(double1 double1In, ..., double15 double 15In) { controller.sendPanelXData(double1In, ..., double15In); } 

(Controller.java [Again x2]):

public void sentPanelXData(double1 double1In, ..., double15 double 15In) { model.receivePanelXData(double1In, ..., double15In); } 

(Model.java [Again x2]):

public void receivePanelXData(double1 double1In, ..., double15 double 15In) { instanceVariable = new AppropriateObject(double1In, ..., double2In); } 

Okay... I hope I don't get too much flak for the length of this question, I rewrote everything to simplify it and hide my specific code.

I want you to see exactly what I am seeing, and this redundancy is what is making me uneasy.

*Sigh*. It works. The issue is that each panel has a different number, and different set of types of inputs, so I cannot simply make one method that could transport them all. So I have about 8 calls that appear in EVERY one of those 4 classes.

If there is some solution to my disgusting implementation of MVC I could delete around 30 methods and make future programmer's lives about 30x easier.. tracing through that line of code is terrible. And I CODED IT. :(

So Question: Should my model be asking the view directly for the panel info rather than going through the controller?

And: Should the model be transmitting its collected info in a better manner that goes directly to the model?

In the past I have seen a similar construct transmit the user input with beans, I was uncomfortable with this approach because they needed them for transmitting over a network, and I am just on one screen with one application.

All the handoffs I am doing here are not expensive.. They don't even factor in when I profile the performance of each method. I know the post is insane, but I would have killed for a post like this with an answer when I was programming this beast.

Answer 1

If you are sending everything through the controller, it's not exactly MVC.

The beauty of MVC is that most of your views "listen" to changes in the model, which means the controller doesn't need to "update" the views for regular data changes. That limits the controller's updating of views to cases where the view needs to be laid out again (such as changing screens, layout, etc).

Models that model changing elements (like clocks) don't even involve the controller. The model calls a (typically) private "changed(...)" method which signals all of the listening views. The views then fetch the data they are interested in (might be different depending on the view), and the view then invalidates itself (to schedule a redraw of itself).

One clock "view" might be a digital clock, another might be a changing non-editable text label, a third a "solar" representation of the sun / moon in different phases (dawn, morning, noon, etc).

Your solution could probably be fixed pretty easily. Initialize the views with a reference to their viewed model and cut out the controller "updating" the view for any data-related stuff. Normally the controller will still have to update the view for certain items, mostly for presentation (which view is visible, etc). Have the assignment of a model to a view cause the view to "unlisten" to the old model and "listen" to the new model. In the model, have any data change notify all the "listeners" of that model object's data change. The "listeners" then need to re-pull whatever data they might be interested in.

Answer 2

Regarding the implementation of MVC my co-workers and myself are against the view accessing to the model and should therefore always go through a controller. Still, if you feel it like having a direct link from view to model you're welcome to do it.

Regarding your 30 methods you should add another layer on top of these and use polymorphism. Create a abstract class where your panels will inherit from or you could implement an interface.

Hope this helped.