Rola EventBus w GWT

Question

Przeczytałem o tej fajnej obsłudze zdarzeń w GWT za pomocą EventBus i do tej pory bardzo mi się podoba. Ale naprawdę nie pojmuję tego pojęcia, kiedy powinienem go użyć. Cały czas? Czy mogę go nadużywać? Czy powinienem używać go do wszystkiego związanego z wydarzeniem? (Podobnie jak komunikacja między warstwą widoku i prezentera w MVP? Czy mogę używać go z zdarzeniem onMouseMove? Jaka jest waga ciężka?)

Tak w jednym pytaniu: Jaka dokładnie jest rola EventBus w GWT?

Answer 1

Myślę, że używanie globalnej EventBus do wewnętrznej komunikacji między częściami MVP pojedynczego widżetu jest nieco nadużywane. To sprawi, że twój widget będzie zależał od eventbus. (Jeśli eventbus nie był w rdzeniu GWT, byłby bardziej obvoiusly nie do przyjęcia.) Uważam, że eventbus jest medium komunikacyjnym pomiędzy różnymi widżetami różnych części aplikacji.

Answer 2

Byłoby całkiem bezużyteczne, aby użyć tego między widokiem a prezenterem, zamiast po prostu mieć prezenter do bezpośredniego wywołania metody widoku.

Wierzę, że EventBus jest dobry, gdy komponenty się nie odwołują, na przykład prezenterów z 2 różnych ekranów.

Answer 3

Prawdopodobnie widzieli Państwo tę prezentację Google I/O: Google Web Toolkit Architecture: Best Practices For Architecting Your GWT App.

Obejmuje on schludne techniki, które ułatwiają pracę z dużymi projektami GWT, takie jak użycie wzorca poleceń dla wywołań RPC, wzorca MVP, iniekcji zależności i oddzielenie komponentów za pomocą wzorca EventBus. Teraz istnieje kilka ram GWT, które implementują te wzory, (GWT-wysyłka wzorca poleceniu GWT-prezenter i GWT-platform dla MVP, GIN & Guice DI), ale co mi się podoba w Koncepcja EventBus polega na tym, że jest częścią podstawowej struktury GWT (HandlerManager), więc nie muszę dodawać dodatkowych zależności do mniejszych projektów GWT.

Myślę, że koncepcja EventBus jest związana z wzorcem projektowania Observer w tym sensie, że oddzielasz komponenty View odpowiedzialne za pobieranie danych od komponentów Presentera, które muszą być powiadomione o tych akcjach. Chodzi o to, że twój ListBox nie musi wiedzieć o wszystkich komponentach, które są zainteresowane zmianą stanu, po prostu wywołuje zdarzenie w EventBus, a zainteresowane komponenty otrzymają to wydarzenie i będą działać tak, jak chcą.

Nie wydaje mi się, że zawsze musisz robić rzeczy za pośrednictwem instancji HandlerManager. Załóżmy, że masz niestandardowy widget, który pozwala użytkownikom wybierać niestandardowe zakresy dat. Ilekroć zakres dat jest zrywane, widżet może zrobić coś takiego w swojej metodzie onSomethingChanged():

NativeEvent event = Document.get().createChangeEvent(); 
DomEvent.fireNativeEvent(event, this); 

Następnie składniki zainteresowane zmianą wyboru zakresu dat może po prostu zarejestrować callbacków händer do wystąpień widget DateRangePicker.

dateRangePicker.addDomHandler(new ChangeHandler(){ 
    @Override 
    public void onChange(ChangeEvent event) { 
     refresh(); 
    } 
}, ChangeEvent.getType()); 

myślę, że to jest ładne luźno projekt i nie używa instancji HandlerManager.

Zły projekt polegałby na wywołaniu wszystkich metod interesującego komponentu refresh() w metodzie onSomethingChange() obiektu DateRangePicker zamiast uruchamiania zdarzenia. (Albo jeszcze gorzej: wywoływanie wszystkich odświeżeń() w podskładnikach obiektu DateRangePicker w metodachSomethingChange().)