¿Debo agregar soporte para PropertyChangeSupport y PropertyChangeListener en un bean Java para una aplicación web?

Question

Me di cuenta de que some people escriben frijoles con soporte para el patrón de Observador de cambio de propiedad.

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); 
    } 
} 

Sin embargo, recuerdo haber leído que el patrón de observador no se utiliza comúnmente en los patrones MVC basados ​​en la web, debido a la naturaleza sin estado de las aplicaciones web.

¿Es una buena práctica seguir el patrón anterior en la aplicación web Java beans?

Answer 1

Para ser sincero, solo molesta si realmente va a necesitar la función. La mayoría de las aplicaciones web no necesitan PropertyChangeSupport. De hecho, no recuerdo haber visto su uso en ninguna aplicación web que haya visto. Solo he visto que se usa una aplicación Swing.

Una típica bean en una aplicación web es un objeto bastante efímero, preparado para atender la solicitud única y luego se envía al vacío para ser recolectada. El problema principal es que las aplicaciones web son mi naturaleza concurrente y multiusuario. Esto no se presta a objetos de mayor duración con oyentes y eventos, etc.

Answer 2

PropertyChangeListener es de todos modos un diseño pobre: ​​toda esa comparación de cadenas mágicas . Mucho mejor opta por un modelo simple con ChangeListener (o similar) y reúnete con modelos compuestos.

A menos que esté haciendo algo interactivo y COMETy, entonces no tiene mucho sentido en una aplicación web. En general, tiene un modelo de extracción donde toda la información actual se incluye de una sola vez. Puede tener sentido dónde tienes cachés.

Incluso puede escribir aplicaciones de escritorio de la misma manera que webapps. Cualquier cambio (o serie de cambios) y sincronizar la GUI. Esto resulta ser bastante compacto. Además, los costos de rendimiento se trasladan desde el momento crítico de los cambios importantes (como abrir una ventana) para extenderse en un tiempo no crítico en el que tiene ciclos para grabar.

Answer 3

1) No agregue soporte de cambio de propiedad a menos que sepa que lo necesitará.

2) Si su bean es solo un objeto de valor con nada más que getters/setters/equals/hashcode, considere usar un marco AOP (Me gusta Spring) para envolver el objeto con los consejos utilizados para implementar eventos de cambio de propiedad /apoyo. De esta forma, su bean no se contamina con la lógica que solo es necesaria en ciertos contextos (generalmente la IU) y que podría cambiar en diferentes contextos. Esta es una lección que aprendí cuando agregué soporte de cambio de propiedades a todos los beans de dominio para una aplicación en particular - la UI lo usó, pero confundió al equipo del servidor (no usado allí) y solo era ruido donde no se usó.

También estoy de acuerdo en que a veces no es necesario que escuche las propiedades individuales, es suficiente para saber si en el objeto ha cambiado.