Должен ли я добавить поддержку PropertyChangeSupport и PropertyChangeListener в компонент Java для веб-приложения?

Question

Я заметил, что некоторые люди пишут бины с поддержкой шаблона наблюдателя изменения свойств.

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

Однако я помню, что читал, что шаблон наблюдателя обычно не используется в веб-шаблонах MVC из-за природы веб-приложений без состояния.

Рекомендуется ли следовать приведенному выше шаблону в веб-приложении Java-бинах?

Answer 1

Если честно, беспокойтесь, только если вам действительно понадобится эта функция. Большинству веб-приложений не требуется PropertyChangeSupport. Я не могу вспомнить, чтобы его использовали в любом веб-приложении, которое я видел. Я видел только то, что используется приложение Swing.

Типичным bean в веб-приложении является довольно недолговечный объект, подготовленный для обслуживания одного запроса и затем отбрасываемый в пустоту для сбора мусора. Основная проблема заключается в том, что веб-приложения являются моей параллельной и многопользовательской природой, что не позволяет использовать их для объектов с длительным сроком действия, со слушателями, событиями и т. Д.

Answer 2

1) Не добавляйте поддержку изменения свойств, если вы не уверены, что она вам понадобится.

2) Если ваш бин - это просто объект значения, имеющий не что иное, как getters / setters / equals / hashcode, подумайте об использовании инфраструктуры AOP (мне нравится Spring), чтобы обернуть объект советами, используемыми для реализации событий изменения свойств служба поддержки. Таким образом, ваш компонент остается незагрязненным с помощью логики, которая необходима только в определенных контекстах (обычно в пользовательском интерфейсе) и которая может изменяться в разных контекстах. Это урок, который я усвоил, когда добавил поддержку изменения свойств ко всем компонентам домена для конкретного приложения - его использовал пользовательский интерфейс, но это сбило с толку команду сервера (там не использовалось) и было просто шумом, когда оно не использовалось.

Я также согласен с тем, что иногда вам не нужно прислушиваться к отдельным свойствам, достаточно знать, изменилось ли что-либо в объекте.

Answer 3

PropertyChangeListener довольно плохой дизайн - все это волшебное сравнение строк. Гораздо лучше пойти на простые модели с ChangeListener (или аналогичными) и собрать вместе с составными моделями.

Если вы не делаете что-то интерактивное и COMETy, то это не имеет большого смысла в веб-приложении. Как правило, у вас есть модель pull, в которой вся текущая информация собирается за один раз. Может иметь смысл, когда у вас есть кеши.

Вы даже можете создавать настольные приложения так же, как веб-приложения. Любое изменение (или серия изменений) и синхронизация GUI. Это оказывается довольно компактным. Кроме того, затраты на производительность переносятся из критического времени серьезных изменений (например, открытия окна) в нерабочее время, когда у вас есть циклы для записи.