Proper model-view-controller design

I have a Java project that I'm trying to implement with a model-view-controller design. I have the backbone of all of the components established. I'm having some trouble deciding on how to connect it all together, particularly the view and the controller.

I have a class called MainView that extends JFrame. I have various other classes that help make up the MainView开发者_运维技巧 each of which extends JPanel. As an example one of these classes is called ParameterView. Should I allow the controller to see each of these "sub-views" or should I let the controller only see MainView and have everything be managed through there?

Likewise with the model, should the model be managed through one overarching class?

Thanks!

In the context of GUI (Swing-like) application, the Model-View-Controller is more of a vague suggestion than a concrete design. The number of variants of this "pattern" is staggering and there is no one "proper" variant you should aim at. You can choose either variant that seems to support your current need (and feel free to change it as your app evolves).

That said, here are some pointers regarding the situation you're describing

• You can use a Publish/Subscribe mechanism (AKA: The observer pattern) or the Chain-of-responsibility patten to decouple model (or parts thereof) from the different parts of the view.
• A facade class (MainView) that packages all parts of the view seems to be a recipe for a "god class": A class that needs to be changed with almost any change in the app (anti pattern). By exposing the differnt parts of the views you will be able to reuse them in new contexts more easily.
• Finally, implementing a model by subclassing Swing components does not seem like a good idea. Such a design is very hard to test which means that it is also very rigid. Prefer delegation over inheritance. Or as JBrains puts it: "Stop subclassing, or the kitten gets it". Use inheritance just for overriding Swing methods. Immediately delegate all logic to objects that are totally isolated from Swing. This will foster testability and future flexibility.

We have had very good results from using Fowler's Presentation Model concept. I strongly recommend that anyone who is doing UI development read Fowler's coverage (GUI Architectures) of the various approaches that have been tried in this arena - it's a fantastic read, and gives great insight in to the challenges and successes of each approach.

It's a good idea to have minimal coupling between layers, so I would probably allow the controller to see only the MainView. You should also consider defining an interface that the MainView implements to make the MVC structure more clear. The controller shouldn't really need to know it's dealing with a JFrame.

Ignoring MVC for a moment, only put Swing-specific code into whatever view components you build that extend JComponent. Delegate everything else to a class you can compile without Swing. Use interfaces to help you with this. Your Controller should be able to handle requests without knowing that they came from a Swing event. Your Model should be able to update the system's state without referring to a Swing *Model class. Your View should be able to describe how to present results to the user without referring to a JComponent class. Once you have that working, you can easily build JComponent objects that delegate to your Model, View and Controller.

I hope that helps you.

MVC is generally Observer (the Model is observable), Strategy (different strategies are swapped into the controller to handle different views), and Composite (the view is a composite of GUI components).

To this end, the controller should be observing the Model and deploying the correct strategies to update your view composite. Your MainView should be able to render the composite items (JPanels?) passed to it from the components. Conversely, the controller should also observe and react to events from the UI, passing them to the appropriate strategy.

Take a look at tikeSwing. It's a simple MVC framework for Swing apps, as explained here.