See http://www.brising.com/MVC.html

Swing gives lip service to MVC, and then does what it pleases.
If you find the result confusing, you're not alone.

Steve

First of all, there is no original definition of MVC, others than that
Smalltalk people claim that what had been implemented in some Smalltalk
version is MVC. This is maybe the root of all the confusion. In order to
"get" THE REAL MVC you are supposed to look at a particular Smalltalk
implementation.

But even with that in mind, one can't claim that Swing does implement
MVC. It doesn't. Not even Sun claimed this. Quote "Swing architecture is
loosely based -- but not strictly based -- on the traditional MVC design.".

http://java.sun.com/products/jfc/tsc/articles/architecture/index.html

Like most "modern" GUI toolkits, Swing doesn't have separate
controllers. Swing basically has widgets, for the view and controller
part (parts of the controller job are also done by the event queue
mechanism). In addition, some of the widgets have corresponding models.
This architecture has a number of names, including Model-View, and
Document-View.

With this setup Swing gives you a chance to structure your application
somewhat MVC-like, or PAC-like, or whatever you want. If you go for an
MVC-like architecture, Swing, like most similar toolkits, suffers from a
 granularity problem: If you really give each and every widget in a
non-trivial GUI an explicit own model, you end up which a large number
of objects and a lot of wiring (to get the event handling in place).
Dead GUI systems like InterViews or it's predecessor Fresco suffered
from this (Fresco has been re-surrected by the Berlin project).

Also, the pre-implemented Swing models most likely don't make up good
models in terms of what your application is all about. This should be
the problem you have with your TreeModel/TabelModel confusion; If you
want to represent the same data as a tree and a list you are either
forced to implement both of the interfaces or to implement some adapter.

Many people have written long articles about how to "fix" (circumvent)
the problems. There should be some good material at
http://www.jgoodies.com/ .

/Thomas

As others have pointed out, you won't find the exact Smalltalk MVC
in Swing. But the Swing architecture shares the motivation behind MVC:
1) separate the domain from presentation and
2) decouple the model using dependents (observer/observable).

I will talk about data binding in a BoF at this year's JavaOne.
And I'm going to upload the presentation from the recent JAX talk.
It'll show up this week at http://www.jgoodies.com/articles/
The slides contain a metamorphosis from (All-together) to M-VC,
to M-V-C, to M-JComponent-VC, to M-JComponent-UIDelegate,
to Swing. And I try to categorize the different model portions:
data model, GUI state model, GUI properties.

It seems to me that many Java developers are confused about
the control behavior portion in Swing. I'd say part of the problem
is, that some people talk about controllers in a way that others
feel a need to implement controllers. If you truely understand
the event handlers in the Swing UI delegates, its fine to mix
the control and view roles in a single class. But I hesitate
to talk about controllers to not confuse developers; instead
I favor to talk about event handlers.

Anyway, I've found that the Swing control and view behavior
is almost irrelevant for the majority of Swing developers;
they can focus on the models and components.
In the talk I demonstrate different styles how to operate on
the Swing data state, GUI state and component properties.

Separate the domain layer from the presentation layer.
Next, decide where you want to hold higher-level models
that adapt or convert your domain object properties:
in the presentation layer or in a model layer that
sits between the domain and presentation layers.

It seems to me that developers I talked to benefit most
from introducing a middle model layer. It helps them
understand where to put what code, where to do what.
My favorite 3-client tier architecture ends up with
a domain layer, with a presentation layer that builds
the UI using models provided by model holders that
lie in the middle model layer. All model operations
can then be performed in the middle layer. Most events
are handled in this model layer too. Only a few handlers
sit in the view layer and switch editable state and
other component properties. I will talk about this in
more detail at the JavaOne.

Choose appropriate patterns for mixing or separating
control behavior with state, or in other words separate
or mix control roles with model roles. In my opinion
a single pattern cannot cover all tasks, requirements,
and application sizes. Instead apply general OO techniques
for finding roles and building classes from these roles.

I'm in the process of writing a Binding Demo that
uses and compares different approaches how to bind
domain object properties to Swing components;
I bind single values and lists. Likely this demo
will be public at the JavaOne.

Only a few parties in the net publish articles around
Swing architectures, data binding techniques and how
to tie a Swing application together. You can find some
papers at Oracle's technology network. Google "JClient",
"ADF". Also google "Model View Presenter" "ValueModel Java".

Hope this helps,
Karsten