GUI layer vs Code layer vs Swing

Question

I always coded console applications and learned some basic UML/patterns skills, using C++.

Now I decided to move to Java and add GUIs to my programs.

The first question is how to handle the GUI layer in the program desing. I mean, how I should separate all the GUI code (adding components, basic event handling) with the code that really does the job (say, when some button is pressed).

Another question its related about the EDT. I read that (almost) all Swing components must run in the same thread (usually the EDT) because of they're not thread safe. So I thought that if "heavy code" it's called from (for example) an ActionListener, then the GUI will become irresponsive for some time until that "heavy code" finish.

That's pretty undesirable, so I think the natural solution is to run the heavy code maybe in another thread or do something like this (I know that this has to be done carefully because I coudn't assume any more that after the user clicked a button, the "deep action" is done before handling another GUI event).

So as you see, I have plenty of questions about how to include GUI in my patterns to keep all quite independent and easy maintainable; and some questions about particular things of Swing components and responsiveness.

I'm sorry in advance for my quite bad english.

Answer 1

Re separating business logic from GUI: If you intend to use Swing, first and foremost study the Model-View-Controller design pattern. It's a good pattern for concern separation and Swing relies on it heavily.

Re heavy-duty code and the EDT: Use SwingUtilities, or even better, SwingWorkers.

Answer 2

You'll find Swing already heavily structured into a MVC variant they call view-delegate.
What you'll need to do is decide how much application logic goes into the GUI layer and there's always some. One thing that helps is that if a gui action is meant to perform a significant task - such as updating some data in a data base, then make sure there's a simple call that the GUI action handler can call which has nothing to do with the gui code/structure. This can be enforced by using Projects in your IDE that have a one-way dependancy. For example, keep all your GUI code in a "gui" project which depends on your "common" project. The "common" project will be able to execute the business logic, but doesn't import swing widgets and can't see your "gui" project.

It's good that you identified the EDT as a key design issue - because it is. SwingWorker has already been suggested by LBT which is a good way to manage long-running gui tasks on a separate thread.