Should I add support for PropertyChangeSupport and PropertyChangeListener in a Java bean for a web application?

Question

I noticed that some people write beans with support for the Property Change observer pattern.

import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
import java.io.Serializable;

public class SampleBean implements Serializable {
    public static final String PROP_SAMPLE_PROPERTY = "sampleProperty";
    private String sampleProperty;
    private PropertyChangeSupport propertySupport;

    public ChartBean() {
        propertySupport = new PropertyChangeSupport(this);
    }

    public String getSampleProperty() {
        return sampleProperty;
    }

    public void setSampleProperty(String value) {
        String oldValue = sampleProperty;
        sampleProperty = value;
        propertySupport.firePropertyChange(PROP_SAMPLE_PROPERTY, oldValue, sampleProperty);
    }


    public void addPropertyChangeListener(PropertyChangeListener listener) {
        propertySupport.addPropertyChangeListener(listener);
    }

    public void removePropertyChangeListener(PropertyChangeListener listener) {
        propertySupport.removePropertyChangeListener(listener);
    }
}

However, I remember reading that observer pattern is not commonly used in web based MVC patterns, due to the stateless nature of web applications.

Is it a good practice to follow the above pattern in web application Java beans?

Answer 1

To be honest only bother if you are actually going to need the feature. Most web applications don't need PropertyChangeSupport. I can't actually remember seeing it being used in any web app that I've seen. I've only seen it being used a Swing application.

A typical bean in a web application is a pretty short lived object, prepared to service the single request and then cast off in to the void to be garbage collected. The main issue is that web applications are my there nature concurrent and multi user this doesn't lend it self to longer lived objects with listeners and events etc.

Answer 2

PropertyChangeListener is of a rather poor design anyway - all that magic string comparison. Much better go for a simple models with ChangeListener (or similar) and bring together with composite models.

Unless you are doing something interactive and COMETy, then it doesn't make a great deal of sense in a web application. You generally have a pull model where all the current information is bundled up in one go. It may make sense where you have caches.

You can even write desktop applications in the same manner as webapps. Any change (or series of changes) and sync the GUI. This turns out to be quite compact. Also the performance costs are moved from the critical time of major changes (such as opening a window) to be spread over non-critical time where you have cycles to burn.

Answer 3

1) Don't add property change support unless you know you will need it.

2) If your bean is just a value object with nothing much more than getters/setters/equals/hashcode, then consider using an AOP framework (I like Spring) to wrap the object with advices used to implement property change events/support. This way your bean stays unpolluted with logic that is only needed in certain contexts (usually the UI) and that might change in different contexts. This is a lesson I learned when I added property change support to all the domain beans for a particular app - the UI used it, but it confused the server team (not used there) and was just noise where it wasn't used.

I also agree that at times you don't need to listen to individual properties, it is enough to know if anything in the object has changed.