Hi all. I'm not very experienced with Swing, so I hope I don't get too confusing or just insignificant here.
The last few days I've been searching a bit about MVC with Swing. After reading some stuff I feel a little disapointed. I might not be right about this, so please correct me if I'm wrong. But here is my thought.
Real MVC is not possible with Swing (as it not possible with a lot of other visual tools either), or just not worth. The controller and the view are very tightly coupled. So, I'll just take it as a "delegate". I can be ok with the controller and view beeing coupled in this visual enviroment (that's how most of these kind of tools work). At this point, we're already talking about a little modified MVC design, but as I said, I can "live" fine with that.
Then, I found out the Swing model classes, created to handle the data related to the gui stuff. I saw a lot of articles on the net about that. However, it turns to be that even those "model" classes are also a little couple to their form of presentation. In other words, if I use a jtable to present my data, I'm supposed to use a tablemodel for it's model. And with it, we're (again) breaking the mvc! Because tomorrow, I might not want to present this data in a table, but as a chart, for example (but all my data is stuck with the tablemodel data structure). I even found some people telling how good the "mvc/swing" based model was because it allows you to change from motif to windows look and feel. Come on, mvc is not (just) about look and feel!
I also found a couple good articles expressing an effort to build real mvc applications with swing, creating an actual model, view and controller. I must say that those ones are nice.
So, I end this post with a question?
- Have anyone actually implemented real mvc in an real application with swing?
As a young developer it seems as if too many people are convinced that MVC is the be all and end all in programming GUIs. I was thrown head first into my first project about two years ago, it's basically a key from image type of application but it's much more than that, incorporating OCR input and content matching. I remember when it was first presented to me, MVC was specifically mentioned, in fact using MVC was a requirement.
A year later I ended up spending about 120 hours redesigning and coding a completely new architecture because using MVC was a disaster. Since then, the project lead and my boss, an experienced programmer of well over twenty years, admitted that ever specifying MVC for this application was a monumental mistake. He said that, in our particular case, it would may serve us well were we to be using C++ but that with the way Swing is designed it didn't serve us well at all. That's the truth.
The point I'm getting at is I think before considering the question of whether or not MVC is possible or worth the effort you should consider the question of whether or not MVC even achieves what you want to begin with. Asking if it's worth the effort kind of presumes that it's even what you want to begin with, and for us it certainly wasn't. When we're talking about Swing, I would gather that in the vast majority of applications it isn't what's best regardless of whether or not it's even possible.
I'm trying to dig up an article I read about a year ago. It basically addressed this subject, and it wasn't about whether not MVC was possible or how to do it. Rather, it addressed why MVC just isn't what you want to be using with Swing in the first place and explained an alternative approach.
So to answer your question: yes, I've written an application using MVC. No, I wouldn't ever do it again, I can't really fathom any case in which I was coding using Swing that it would be appropriate.
As for our current design, we have completely seperated our data from it's presentation as you would in MVC, but it's not using MVC. It's late and I'm not thinking so well, but I believe our design does fit a pattern I just can't remember the name of it, it's similar to MVC. It's not that we tried to follow a pattern, that's just where our development logically took us, and it happens to mirror almost exactly the kind of approach that was in that article.
There are a couple issues going on. First as you bring up using MVC directly at the Swing level (or that of most modern UI toolkits) is difficult. Controllers/models already exist to handle raw user input. I still think MVC can be useful in overall application design. However, this is normally when you have a nested MVC type design.
The MVC triad that exists at the lower levels of your application is likely to have "input" that isn't mouse clicks but application events. The "views" are logical ones at levels below the UI toolkit being used.
In relation to the layer that consists of UI widgets/models and the data models just below them I would suggest using the MVP or Presentation Model pattern.
In MVP the controller is replaced with a Presenter that contains the behavior of the view. This allows the class to handle the logic needed for the view but not worry about raw user input. View related state is stored in the view itself.
In PM both the behavior and state of the view are pulled out into the Presentation Model class. The view just becomes a reflection of that state. JGoodies Binding is an excellent library to assist presentation model designs.
Finally, in regards to your points about Swing models I have found the following to be useful. The Swing models as you mention are there to support the Swing components not your data object directly. I've found it useful to write adapter models that decorate your existing objects/models with a layer that is compatible with the Swing models. If you need to transform your data to prepare it for use in the UI, this logic can be placed in the presenter/presentation model layer to create an intermediate model that is closer the the final UI form. This also allows you to easily test this transformation logic. You can adapt this intermediate model to the appropriate JTable/chart models as you see fit in the view layer.