Although I have tried to use MVC for Web applications (where to be frank I implemented a greatly simplified version of Struts without realising it) I have never been quite sure as to the benefit of doing so in a Swing application nor exactly how if I am honest.
Now though I have much more incentive to learn how to do it properly. The introduction of the excellent GUI builder Matisse in NetBeans means that it is incredibly easy to knock up a Swing GUI quickly. However to really get the maximum benefit I can see that it is important to separate the actual implementation of the underlying logic of the application from the generated code. This was exactly the problem that used to occur with Forte, JBuilder and Cafe. You would have a big wodge of generated GUI code and then an unrelated and unmanaged block of application code that often had to reside in the generated GUI code to make.
In addition I have also comes across an incredibly obtuse MVC implementation at work. This reminds me of my own attempts to implement MVC for web applications. You kind of know the principle but you’re not sure what that translates to in terms of the concrete classes and code you have to produce. I don’t personally believe in spending a lot of time bringing existing code up to scratch where you know the underpinnings are not strong. It is easier and probably better to look at what the code is meant to do and then implement that correctly rather than end up painting yourself into a corner by trying to reconcile the purpose of the code with its current implementation.
To help my understanding of MVC in a Swing application I therefore want to have a very simple reference application I can use to build up my understanding of how such an application should work and be implemented. I’ve chosen to do a very simple ToDo list application based on the Google ToDo list plugin for their Desktop app. This would be handy for me personally as I need such an application and also removes a lot of the issues with designing the application by providing a reference for the behaviour.
Next step then a few uses-cases/activity diagrams and a class diagram for the model.
Echo One 
I actually did a Swing application that was *SORT OF* MVC, and it worked like this:
The model was composed of a number of classes representing user information and stored information from forms the user was submitting… All database access went on in these classes, and they provided getters and setters as well as methods for saving, deleting, updating and querying the data (for instance, to load a form, you’d call its fetch method and pass it the unique ID you were interested in).
The view was a number of GUI windows, each of which related to different tasks. These would accept the data object related to the task (model) by reference, along with a reference to the calling window. On completion of the task, a “refresh” method in the calling window would be called to show any changes in the displayed data, then the current window would be disposed of, and control would shift back to the calling window.
The controller turned out to be more virtual, spread across all the GUI-related files… Because all my windows would be acting as views, and all my backend data objects were acting as models, and because I was using NetBeans, the code behind the GUIs was essentially the controller and Swing took care of the rest. When you right click on a form element and assign code to the handler for it, you’re writing controller code, right?
I think the controller in a Matisse/Swing app is a combination of all the event code of all the GUI objects, and only exists *AS a controller* in a virtual sense. If you go to the source view, the GUI code is actually not editable; NetBeans keeps it separate from the code YOU write, which ends up acting as the controller.
Or maybe I’m missing something… It struck me that if I hand-wrote a whole separate Java class with a main() method, and tried to bury all the event handlers and controller code in there, it would actually make my apps HARDER to work on, rather than easier. It didn’t seem like a sound approach.
Of course, I’m still learning.
It’s been ages since I looked at this problem (although it has always been rumbling on in the back of my mind). The new Beans Binding API (https://beansbinding.dev.java.net/) is being pushed as a way of automatically synchronising databeans and Swing components (which are of course beans themselves).
This solution seems to me to be the best solution to the generated code dilemma as you only need a reference to the Swing component when initiating the model (or delegate) code.
I haven’t actually tried combining it with Matisse but it is definitely a task that will be going into my todo list.