我注意到some people写了bean,支持Property Change观察者模式。
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);
}
}
但是,我记得由于Web应用程序的无状态特性,观察者模式并不常用于基于Web的MVC模式。
在 Web应用程序 Java bean中遵循上述模式是一种好习惯吗?
答案 0 :(得分:10)
说实话,如果你真的需要这个功能,那就太麻烦了。大多数Web应用程序不需要PropertyChangeSupport
。我实际上不记得看到它被用在我见过的任何网络应用程序中。我只看到它被用于Swing应用程序。
Web应用程序中的典型bean
是一个非常短暂的对象,准备为单个请求提供服务,然后转入void以进行垃圾回收。主要问题是Web应用程序是我的自然并发和多用户,这不会让自己适应具有监听器和事件等的长寿对象。
答案 1 :(得分:3)
PropertyChangeListener
无论如何都是一个相当差的设计 - 所有魔术字符串比较。更好的是使用ChangeListener
(或类似)的简单模型并将其与复合模型结合在一起。
除非您正在做一些交互式和COMETy,否则它在Web应用程序中没有多大意义。您通常有一个拉模型,其中所有当前信息一次性捆绑在一起。在你有缓存的地方可能有意义。
您甚至可以像使用webapps一样编写桌面应用程序。任何更改(或一系列更改)并同步GUI。事实证明这非常紧凑。此外,性能成本也会从重大变化的关键时间(例如打开一个窗口)转移到非关键时刻,在这个时间点你有刻录周期。
答案 2 :(得分:3)
1)除非您知道需要,否则不要添加属性更改支持。
2)如果你的bean只是一个只有getters / setters / equals / hashcode的值对象,那么考虑使用AOP框架(我喜欢Spring)来包装对象,用于实现属性更改事件的建议/支持。这样,您的bean就不会受到某些上下文(通常是UI)中需要的逻辑的影响,并且可能会在不同的上下文中发生变化。这是我在向特定应用程序的所有域bean添加属性更改支持时学到的一个教训 - 用户界面使用它,但它混淆了服务器团队(在那里没有使用),只是在没有使用它的噪音。
我也同意,有时您不需要听取个别属性,只需知道对象中的任何是否已更改。