tags:

views:

112

answers:

2

There are many examples on the web when it comes to the MVC pattern with Swing. However, there doesn't seem to be a straightforward way of doing things.

Here's some questions:

  1. Can the notion of View be directly associated with Swing components such as JFrames?
  2. Likewise, can the existing model classes that Swing uses be used as the Model or should one basic model be adapted through several Swing model classes?
  3. If the answer to 2 is yes, should these Model classes be centralized in one class (attribute/Composite) or grouped in a package (one class per separate Model)?
  4. If Model classes remain separate, does this mean that there can be several MVC patterns running at the same time in a typical application?
  5. Is a one-on-one correspondance between a model, a view and a controller an imperative or can more than one controller/view exist for one given model?
  6. Finally, how could an application be structured so it's easy to maintain?

Some links:

+2  A: 

This article on Java SE Application With MVC seems to answer your question: http://java.sun.com/developer/technicalArticles/javase/mvc/

UPDATE: The model should fit with how you want to store the data, don't force your solution to use some generic model. For example, if you have tabular data, you may want to have one view to show it as a 3D graph, another as a spreadsheet. One model, multiple views.

The basic idea is separation of your code, to make it more flexible and maintainable. So, I tend to start with what my data is going to be, so I design the model first, then I start to work on the first view, and then, as I work on each view, for that model, I may find that I need to add to my model, or make it more generic than I had originally. While I am doing this, I have to work on the controller(s), and depending on complexity I may have several controllers, rather than forcing one controller to be doing too much.

Good design is important in MVC, so determine what views may be reasonably used by your design, as well as determining the models you will need for your data. The controller just ties these two together.

But, you will find frameworks that use one main controller calling other controllers, and that is fine, but, find a design that makes sense in terms of adaptability and maintainability.

James Black
Ok, so they seem to recommend the MVC as described on Emilio's site (controller as mediator). To summarize, a Model extends AbstractModel, a Controller extends AbstractController and, from the source code, it appears the View is using a JPanel. From the main it looks like there is one controller and several Models/Views. That should help. Thanks :) .
James P.
+1 I had previously overlooked this excellent article, confounding it with an older one using the same diagram: http://java.sun.com/blueprints/patterns/MVC-detailed.html
trashgod
+3  A: 

A JFrame, like all top-level containers, makes an excellent view implementation; I typically use JPanel to organize the JComponent subclasses that constitute related view elements.

The model should have no knowledge of the view(s); it notifies observers (listeners) of changes in state, typically in response to the invocation of its methods.

An application may have more than one model, and each model may have more than one view. Swing itself uses a related separable model architecture, as discussed in A Swing Architecture Overview.

Here's very simple example that you may find instructive.

trashgod