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

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

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.

StackExchange Code Review Q#7901, answer score: 4