GWT 中的 EventBus 角色

发布于 2024-12-18 22:16:39 字数 215 浏览 7 评论 0原文

我在 GWT 中使用 EventBus 阅读了有关这种很酷的事件处理的信息，到目前为止我真的很喜欢它。但我不太明白这个概念什么时候应该使用它。一直吗？我可以过度使用它吗？我应该将它用于所有与事件相关的事情吗？（就像 MVP 中视图和演示者层之间的通信？或者我可以将它与 onMouseMove 事件一起使用吗？它有多重量级？）

那么有一个问题：EventBus 在 GWT 中到底扮演什么角色？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

清风疏影 2024-12-25 22:16:39

您可能已经看过此 Google I/O 演示文稿：Google Web Toolkit 架构：最佳构建 GWT 应用程序的实践。

它涵盖了使大型 GWT 项目更易于管理的巧妙技术，例如使用 RPC 调用的命令模式、MVP 模式、依赖注入以及使用 EventBus 模式解耦组件。现在有几个 GWT 框架实现了这些模式（用于命令模式的 gwt-dispatch，用于 MVP 的 gwt-presenter 和 gwt-platform， GIN 和 Guice for DI），但我喜欢 EventBus 概念的一点是它是核心 GWT 框架 (HandlerManager) 的一部分，所以我不必添加额外的依赖项到较小的 GWT 项目。

我认为 EventBus 概念与 Observer 设计模式相关，因为您正在解耦负责从需要通知这些操作的 Presenter 组件获取用户输入的 View 组件。关键是你的 ListBox 东西不必知道所有对其状态变化感兴趣的组件，它只是向 EventBus 触发一个事件，感兴趣的组件将接收该事件并按照他们想要的方式执行操作。

不过，我认为您并不总是必须通过 HandlerManager 实例执行操作。假设您有一个自定义 DateRangePicker 小部件，可让用户选择自定义日期范围。每当选择日期范围时，小部件都可以在其 onSomethingChanged() 方法中执行类似的操作：

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

然后对日期范围选择更改感兴趣的组件只需将处理程序回调注册到 DateRangePicker 小部件实例。

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

我认为这是一个很好的松散耦合设计，并且它不使用 HandlerManager 实例。

糟糕的设计是在 DateRangePicker 的 onSomethingChange() 方法中调用所有感兴趣组件的 refresh() 方法，而不是触发事件。（或者更糟糕的是：调用 DateRangePicker 对象的子组件的 onSomethingChange() 方法中的所有刷新（）。）

You have probably seen this Google I/O presentation: Google Web Toolkit Architecture: Best Practices For Architecting Your GWT App.

It covers neat techniques to make working with a large GWT projects more managable, like using the Command Pattern for RPC calls, the MVP pattern, Dependency Injection, and decoupling components using the EventBus pattern. Now there are several GWT frameworks that implement these patterns, (gwt-dispatch for Command pattern, gwt-presenter and gwt-platform for MVP, GIN & Guice for DI) but the thing I like about the EventBus concept is that it's part of the core GWT framework (HandlerManager), so I don't have to add extra dependencies to smaller GWT projects.

I think the EventBus concept is related to the Observer design pattern in the sense that you are decoupling the View components responsible for getting user input from the Presenter components that need to be notified about those actions. The point is that your ListBox thingy doesn't have to know about all the components that are interested in its state change, it just fires an event to the EventBus, and the interested components will receive that event and act however they want.

I don't think you always have to do things through the HandlerManager instance though. Suppose you have a custom DateRangePicker widget, that lets users pick custom date ranges. Whenever a date range is picked, the widget can do something like this in its onSomethingChanged() method :

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

Then the components interested in the date range selection change could just register hander callbacks to the DateRangePicker widget instances.

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

I think this is a nice loosely coupled design and it doesn't use a HandlerManager instance.

A bad design would be to call all the interested component's refresh() methods in the DateRangePicker's onSomethingChange() method instead of firing an event. (Or even worse: calling all the refresh()-es in, the DateRangePicker object's subcomponent's onSomethingChange() methods.)

回复收藏 0 原文