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在“ 軟件開發思想”博客上的過時做法。