Java MVC - Doesn't feel like I get it

Answer 1

MVC is an interesting abstraction, but has some problems.

In reality, the controller and view are often paired--even though in theory you should be able to replace either one without the other, in reality the interface mechanisms to different views are so different that the controller & view are combined.

The best description I've seen relating to Java is that the view is your swing components so your portion of the view code is nothing but placing those components on the screen.

Your controller is the rest of that class, the listeners and the rest of your code that interacts with the view.

My suggestion would be to not worry too much about isolating the view and controller, but that said, I am totally behind keeping a very strong separation between the model and the view/controller.

EDIT/Advanced: I have used a pattern where controller and view are isolated and it is more flexible, but it tends to be a lot more work. I think Struts uses the binding model--if you want to see some abstraction techniques you might look there or search for stuff about "binding" swing controls.

Answer 2

From my perspective, this is something I ran into when I first tried to separate out my Models, Views and Controllers in my first desktop application.

With Web Applications, the MVC pattern fits VERY naturally because of the innate nature of the web, but unfortunately it's not possible to fit a pure MVC patter to a desktop app, where the Operating system plays an innate role in notifications. This usually leads to the pattern being implemented as you've shown in your diagram.

However the pattern that you've shown really needs to be implemented like this, I think (I've switched over to .NET after a brief affair with Java, so please keep that in mind):

public class ContactManagerMainScreenModel
{
    ContactManagerMainScreen v;
    // Loading Local Storage
    LocalContactStorage LocalContactStorage = new LocalContactStorage();
    // Favorite list
    boolean showFavoritesList = true;

    public void register(ContactManagerMainScreen v)
    {
        this.v = v;
    }

    public void ShowOrHideFavoritesList()
    {
        if(showFavoritesList) 
        {
            showFavoritesList = false;
            v.RefreshView(this);
        }
        else
        {
            showFavoritesList = true;
            v.RefreshView(this);
        }
    }
}

Meanwhile the controller would be responsible for receiving user actions. So if you have a button that says "Toggle Favorites", this would cause the controller to call _model.ShowOrHideFavoritesList(). The model would update itself and ask the view to refresh itself using it's new state.

The view would now be free from the dependency on the controller.

Answer 3

I don't think that diagram is very good, and probably makes things a lot more confusing.

The controller should be responsible for giving the Model to the View. The Model should contain nothing more than simple accessors for your data. Any need to interact with the Model - or change any of it's values - should take place thru the Controller.

This way, the View only needs to know how to render/present the Model to the user. So any operations on the Model - things like saveFavoriteContactsToLocalStorage() - should be methods of the Controller, not the View class. Also, the Controller should not need a reference to the View to be constructed - I think that ends up reversing the intended order of the entire MVC pattern.

Answer 4

I agree with Bill K. Standard MVC is not that important when dealing with rich client. It is a great model when writting web apps as events (clicks in your browser) are quite different than your view (HTML render).

With standard GUI, a better model is something called PAC (presentation/abstraction/Control). Here the presentation is (the view + the event handler), the controller manage the exchanges between the presentation and the abstraction. And the abstraction is your business model.

This way you have a controller that manage the link between the GUI part (view + user events) and your abstraction. You have a PAC agent for any piece of GUI you develop and a clean separation between them.

Another article about something better than MVC related to PAC : HMVC. Quite old, but it is practical and it helps understanding things.