JSF基于事件的沟通：过时的方法

用JSF编写的Web应用程序由相互交互的bean组成。在开发Web应用程序时，bean之间的通信是主要的设计模式之一。有时，一个bean需要向其他bean发送事件，以通知它们某些更改或其他任何更改。我们通常可以将托管bean或Spring bean注入另一个bean的属性中，以便另一个bean可以直接通知注入的bean。注入是好的，但是它并不是出于交流目的而引入的。它与动态的松散耦合系统相距甚远，在该系统中，每个bean都不了解其他bean。在松耦合系统中，我们需要一种基于事件的良好通信机制。这篇文章将涵盖两种设计模式：观察者/事件监听器和中介者模式。这些模式如今已在许多Web应用程序中广泛使用，但是它们具有缺点。该系统并不是真正与它们松散耦合。有很多更好的现代方法。因此，我在帖子名称中写了“ Old-school approach”。新学校的方法将在下一篇文章中公开。

观察员/事件听众

我们将从观察者（也称为事件监听器）模式开始。一个称为主题或可观察对象的对象会维护其依赖项的列表（称为观察者），并自动将状态变化通知他们。在Java中，有一些类java.util.Observer和java.util.Observable可以帮助实现此模式。通过此模式进行的基于事件的通信的其他相关构造是类java.util.EventObject和接口java.util.EventListener。让我们开始编码。假设我们有一个I18N Web应用程序，并且用户可以在用户设置中的某处选择一种语言（语言环境）。假设我们有一个名为UserSettingsForm的bean，它负责用户设置。某些会话作用域的Bean可以保留I18N文本/消息，因此，当用户更改当前语言时，需要以最后选择的语言重置以前的文本/消息。首先，我们需要一个LocaleChangeEvent。

public class LocaleChangeEvent extends EventObject {Locale locale;public LocaleChangeEvent(Object source, Locale locale) {super(source);this.locale = locale;}public Locale getLocale() {return locale;}
}

其次，我们需要一个接口LocaleChangeListener。

public interface LocaleChangeListener extends EventListener {void processLocaleChange(LocaleChangeEvent event);
}

我们的UserSettingsForm现在可以通过注册字符串并通知它们来管理LocaleChangeListener类型的实例。

@ManagedBean
@SessionScoped
public class UserSettingsForm implements Serializable {private Locale selectedLocale;private List<SelectItem> locales;private List<LocaleChangeListener> localeChangeListeners = new ArrayList<LocaleChangeListener>();public void addLocaleChangeListener(LocaleChangeListener listener) {localeChangeListeners.add(listener);}public void localChangeListener(ValueChangeEvent e) {...// notify listenersLocaleChangeEvent lce = new LocaleChangeEvent(this, this.selectedLocale);for (LocaleChangeListener lcl : localeChangeListeners) {lcl.processLocaleChange(lce);}}...
}

方法localChangeListener（）是JSF ValueChangeListener，可以在例如h：selectOneMenu中应用。每个实现LocaleChangeListener的bean都应该由UserSettingsForm注册，以便通过语言环境更改得到通知。

@ManagedBean
@SessionScoped
public MyBean implements LocaleChangeListener, Serializable {// UserSettingsForm can be injected e.g. via @ManagedProperty annotation or via Spring facilityprivate UserSettingsForm userSettingsForm;@PostConstructpublic void initialize() {userSettingsForm.addLocaleChangeListener(this);}public void processLocaleChange(LocaleChangeEvent event) {// reset something related to I18N data...}
}

就观察者模式而言，UserSettingsForm是可观察的，而LocaleChangeListener的实例（如MyBean）则是观察者。讨论的模式带有一些您需要注意的重要问题。豆紧密耦合。有很多手动工作来重新注册bean。 Bean必须实现定义的接口。如果您有100个语义不同的更改通知了bean，则它必须实现100个接口。无法通知已注册的侦听器的子集–即使不需要通知所有侦听器，也总是会通知他们。最后但并非最不重要的– 内存管理问题。马丁·福勒（Martin Fowler）写道： “假设我们有一些观察某些域对象的屏幕。 关闭屏幕后，我们希望将其删除，但是域对象实际上通过观察者关系携带了对屏幕的引用。 在内存管理的环境中，寿命长的域对象可能会占据很多僵尸屏幕，从而导致大量内存泄漏。”

调解员

与“观察者/事件侦听器”模式相比，“中介者”模式改善了基于事件的通信。使用中介者模式，对象之间的通信将与中介者对象一起封装。对象不再彼此直接通信，而是通过调解器进行通信。这减少了通信对象之间的依赖性。我们将看到它如何用于JSF-Spring Bean（在上面的示例中是标准托管Bean）。我们将实现一个Mediator类来管理作用域bean之间的通信。重要的是要理解一个bean只能通知范围更广的另一个bean。视图作用域的bean可以通知视图作用域的会话，会话作用域和应用程序作用域的bean，但不能请求作用域较小的作用域的bean。请遵循此规则以避免麻烦。这是作用域Bean的一种特性–您可能还记得，可以始终将作用域更广的bean注入到作用域更窄的bean中，反之亦然。为了开始使用Mediator，我们将引入两个接口MediatorEvent，MediatorListener和中心类Mediator。

public interface MediatorEvent {...
}public interface MediatorListener {public void listenToEvent(MediatorEvent event);
}public class Mediator implements Serializable {private Collection<MediatorListener> collaborators = new HashSet<MediatorListener>();public static Mediator getCurrentInstance() {// access Mediator bean by JSF-Spring facilityreturn ContextLoader.getCurrentWebApplicationContext().getBean("mediator");}public void fireEvent(MediatorEvent event) {for (MediatorListener mediatorListener : collaborators) {mediatorListener.listenToEvent(event);}}public void addCollaborator(MediatorListener collaborator) {collaborators.add(collaborator);}public void removeCollaborator(MediatorListener collaborator) {collaborators.remove(collaborator);}
}

介体是一个有作用域的bean，可以注册并通知协作者。协作者通过调解员进行注册。在Spring中，bean可以实现接口InitializingBean，以便在bean实例化之后自动调用afterPropertiesSet（）方法。这类似于@PostConstruct。 afterPropertiesSet（）是此类bean通过介体注册的正确位置。 Bean还应该实现MediatorListener以便被通知（请参见listenToEvent（））。

public MyBean implements MediatorListener, InitializingBean, Serializable {public void afterPropertiesSet() throws Exception {...Mediator.getCurrentInstance().addCollaborator(this);}@Overridepublic void listenToEvent(MediatorEvent event) {if (event instanceof LocaleChangeEvent) {// do something}}
}

我们将在UserSettingsForm和区域设置更改中使用相同的方案。由Mediator注册的Bean将通过fireEvent（）进行通知。

public class LocaleChangeEvent implements MediatorEvent {...
}public class UserSettingsForm implements Serializable {private Locale selectedLocale;private List<SelectItem> locales;public void localChangeListener(ValueChangeEvent e) {...// notify listenersMediator.getCurrentInstance().fireEvent(new LocaleChangeEvent(this, this.selectedLocale));}...
}

调解器模式提供了豆之间更好的耦合，但是它们仍与调解器耦合。进一步的缺点：仍然需要手动注册bean –请参见附加代码Mediator.getCurrentInstance（）。addCollaborator（this）。每个bean仍应至少实现一个MediatorListener，这会带来另一个约束– listenToEvent（）。每个bean都应实现此接口方法！ JSF中介体模式的最大缺点可能是它是有作用域的bean。视图作用域调解器只能与视图作用域的bean一起顺利使用。当视图作用域调解器被销毁时，注册的视图作用域Bean将自动删除。其他情况可能会导致内存泄漏或几个问题。例如，应该通过调用removeCollaborator（）手动删除由视图作用域介体注册的请求作用域Bean（很容易忘记）。会话作用域的Bean应该由会话作用域的介体注册，否则销毁视图作用域的介体后，它们将不会得到通知。等等

实际上，中介器模式仅比常规的“观察者/事件侦听器”概念好一步。有更灵活的方法，其中“任何方法”都可以捕获引发的事件，而不仅可以修复指定的问题，例如listenToEvent（）。在下一篇文章中，我们将看到简单而简单的方法，如何仅通过一种方法和其他建议来捕获乘法事件。

参考： JSF中基于事件的通信。我们的JCG合作伙伴 Oleg Varaksin在“ 软件开发思想”博客上的过时做法。