views:

173

answers:

2

I'd like to add persistence to my Swing-based application; and this is the first time that I'm doing something like that.

I know how to use Java serialization APIs (though I'm using xstream instead), I know that JComponent's are serializable, but I'm interested in more architectural considerations: how an application should be designed so that making it persistent becomes easy; etc.

I'd be happy to see any sources with in-depth consideration of these issues, though I'd be also happy to hear some best practices explicitly :)

+6  A: 

You should use a model-view-controller approach. You only serialize the model, not the view. The view should be populated from the model. Serializing Swing components is anyways not recommended at all:

While Swing components do implement the Serializable interface, they are not portable between different versions of the Java Virtual Machine

Looking at what you have, you should have some classes that are your model and have only data. These classes will be serialized using XStream somewhere. Your Swing Classes then have methods to receive these model classes and populate the fields and editors. You can then extend the UI, for example, without having to change the class, adding more funcionality, or provide different views for the same data set.

To make it fancier, the Swing Component should not store and load the model, but you should have a controller interface that you pass to the swing component to perform these operations. This way, you can unit test better and you decouple the storage logic from the view logic.

If XStream is correctly configured, and if you are careful about the model and the fields, it should be possible to add more fields to your model classes without breaking backwards compatibility.

I don't recommend using Java Serialization anyways, as it is not a good practice to use it for storage. Java Serialization excels at Remote Method Invocation. It is relatively fragile when the model classes change..

Mario Ortegón
A: 

And the javadoc says (for instance on JComponent): As of 1.4, support for long term storage of all JavaBeansTM has been added to the java.beans package. Please see XMLEncoder.

So see XMLEncoder.

From architectural point of vue, this serialization work best with beans, collections, and the notion of default value. On beans, it save only properties beans with a different value than default value. (sorry for my english)

You can configure that as you want.

Istao
If the java bean is new and used for data, XMLEncoder is a good idea. Otherwise, I still think that serializing a JComponent is in general a bad practice.
Mario Ortegón
@Mario Ortegón : Yes I agree ; but man can see the "bean version" of a JComponent as a ligth design model : there no the listeners, for instance, only color, background, position... So, if we want to serialize / deserialize, it's necessary to rebuild controler logic. I think XML encoder is not very good, but it's not very bad. It's interesting :-)
Istao