MVC and Swing in desktop application

Question

After realizing that I have completely ignored the MVC pattern I have tried to utilize the concept in an application with a Swing view. I have now read most of the posts on the subject of MVC with Swing but am still a bit confused, because it is too complicated for me to grasp, and I think I need some basic clarifications so I don't set off on the wrong path.

I also wonder how common it is to use MVC in real projects. Many online tutorials seem to leave out the controller and mix it with the model, while I was confused by XSTL:s business logic capabilities. Why would you want to address a datasource from a JSP view?

These thoughts aside, my proper question is this:

If you have a Swing component, should event listener in that Swing class update the component state through calling (static perhaps?) methods in a POJO controller class, which in turn gets the appropriate business logic from the model, which is made up by POJO class hierarchy and associated persistence?

Answer 1

I've worked as a freelance for a long time and almost 90% of the projects were about Java Swing (Desktop applications). Also a lot of projects involved migration from languages like Visual Fox Pro to Java, it was a pain, because the hard part is not think in the logic which is already done, the hard part is take the code that is a mess and turn it into a good-looking code following the good practices and using design patterns, that's why it is a good idea to make a schema or a map in your mind how you can separate your code following the concepts of Model, View, Controller.

MVC as mentioned helps you to have a good-looking, maintainable and easy to read code, as well as you follow the programming paradigms and good practices.

View: Obviously, the part that interacts with the user (user interface), in case of Swing, your windows, frames, panels and all the code that involves the graphic components you need for your app.

Controller: Involves the core or business logic you stablish for your application, in this "layer" you should include the functionality and the "how my application will achieve the goals?".

Model: Related with the data you manage, for example, your entities and classes that represents the data you want to manage or give maintenance.

Applying MVC is not so hard, but as I mentioned, it could be sometimes a pain when you have to migrate your code from a not-applying-MVC structure to a MVC structured application. It is easier to start coding using MVC.

A way I get used to it is by using maven and separate my application into little "modules", of course, you don't need maven, I just found it useful in that moment, but in any case you can try practicing or get used to MVC by separating your application into little projects, for instance:

Java Project 1: application-data-model (contains all the code related with data management: entities, dtos, beans, daos)

Java Project 2: application-core-controller (contains all the business logic and functionality, you can use a facade pattern here if you want to make your code more "transparent" when you relate with your view)

Java Project 3: application-view-ui (contains all the panels, frames and graphic components)

Working this way helped me (and forced me) to get used to separate my code and keep an eye on what really matters to the project I'm working on. For instance, if I'm on application-data-model I'm focused in data model, I'm not thinking in business logic nor graphic interface.

Long explanation, maybe somebody could do it better, but hope I could have helped you or at least gave you a hand with this.

Best regards.

Answer 2

Firs the URL for basic understanding of MVC

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Now the approach to implement it in Swing applications. Don't get confused with controller functionality with the listeners functionality.

1. UI controls and listeners attached to them should be defined in your view classes.
2. On any event, whenever you need to invoke a business logic, then you need to call the controller class. Like fetching some value from the database.
3. Controller class should talk to your model to fetch the data and manipulate it if required.
4. Model classes should work on the data.

The idea of using MVC is to reduce redundant code and more manageable code. So if you are doing some calculations/manipulations then those can be moved to Controllers. Controllers can be called from different views requiring the same stuff. Similarly model can be used by multiple controllers to fetch the data.