java - 最有值(value)球员 : : Event Bus pattern instead of Listener

Question

这个问题更倾向于范式。为什么我们不在 MVP 环境中使用事件总线而不是监听器？通常，“P”部分具有 View 和模型引用的依赖注入(inject)。当然，这有一个优势，即通过 Presenter 显示 View 和模型之间的明确契约，这更具可读性。

但是，让演示者从 View 中监听事件并且事件携带 View 有效负载(例如:json 表示)不是一种更简洁的方法。演示者回话 View 也是如此。 View 将监听来自演示者的事件。主要优点是，我们不必为 View 和演示者之间的每个契约编写接口(interface)。如果您查看 code你会看到演示者正在接触文本字段等 View 细节，我相信这会增加 View 和演示者之间的耦合。比如说，如果我要替换前端 JavaFx 而不是 Vaadin，我也将不得不更改 Presenter。

这个类是一个实时项目的例子。这里我们有不同类型的事件，即我不为不同的情况创建事件类。例如: LoginViewEvent ， DashBoardEvent 等，我认为这是一个维护难题。

public class UrayEvent {

    public static enum EventType {

        SESSION_SELECTED(1),
        DOCUMENT_SELECTED(2),
        DOCUMENT_EDIT_COMPLETE(3),
        DOCUMENT_EDIT_CANCELED(4),
        SHOW_SESSION_TABLES(5),
        SHOW_SESSION_DOCUMENTS(6),
        SHOW_SESSION_COLLABORATORS(7),
        USER_REQUESTED_REFRESH(8),
        AUTO_REFRESH(9),
        TABLE_SELECTED(10),
        DETACHED(11),
        SCHEDULER_NAVIGATION(12),
        JIRA_USER_SELECTED(13),
        DOCUMENT_SAVE_SUCCESS(14),
        DOCUMENT_SAVE_FAILURE(14);

        private final int value;

        private EventType(int value) {

            this.value = value;
        }

        public int getValue() {

            return value;
        }
    }

    public static class Event {

        private final EventType type;
        private final Object payload;

        public Event(EventType type, Object eventPayload) {

            this.type = type;
            this.payload = eventPayload;
        }

        public EventType getEventType() {

            return type;
        }

        public Object getEventPayload() {

            return payload;
        }
    }

}

很简单， View 发送事件 DOCUMENT_EDIT_COMPLETE 。展示层处理这个事件。我发现这种方式是将 View 与演示者分离的更好方法。

    @Subscribe
    public void handle(UrayEvent.Event event) {

        switch (event.getEventType()) {
            case DOCUMENT_EDIT_COMPLETE:
                  // event payload contains document model data
                  // like document id etc
                 saveDocument(event.getEventPayload);    
                break;
            default:
                break;
        }
    }

优势

• 更少的样板代码，对于 n-views 我们不需要 n-interfaces
• 新事件意味着将事件元素添加到枚举并更新相应的订阅处理此事件的方法。

缺点

• 如果我们忘记从 eventbus 中注销，则会发生内存泄漏(面对它有足够的时间)

问题

1) 这种方法意味着，随着应用程序的增长，会有更大的集合枚举元素。这种方法是反模式吗？

2) 如我们所见，它广泛使用事件总线，有什么缺点吗？使用总线系统而不是接口(interface)监听器模式？

希望您在这方面提出宝贵意见。主要问题是，如果我在整个项目中盲目地广泛应用这种模式，我不应该后悔这样做，这种方法可能存在的陷阱是什么。

Answer 1

1) This approach means, there would larger set enum elements as the application grow. Is this approach an anti pattern ?

如果有很多事件，您需要很多事件标识符。它们可以是简单的 int 或 enum 或 Interface。

您演示的机制很简单，适用于小型应用程序。它已被多个框架多次证明。以微软的 Win32 API 和 MFC 为例。

在一些项目中，我看到了使用 Annotation 实现的事件拦截器，它提供了一种处理事件的优雅方式。上一次是在一个使用Apache Wicket框架的项目中。

2) As we saw it uses Event Bus extensively are there any drawbacks of using bus system instead of interface-listener pattern ?

基本上是同一个东西，不同的包。在 Java 世界中，使用监听器接口(interface)是事实上的标准。以 Swing 和 Android 为例。

事件总线方法用于 Facebook 基于 Javascript 的 React 框架。注意到 Model-View-Presenter 和 Flux 设计模式的相似性很有趣。特别是在两种架构中都突出了单向数据流。

您提到用 Vaadin 替换 JavaFx 作为 UI 框架的用例。在我看来，更改 UI 框架以便您能够重用它的某些部分的情况很少发生。我不会因为框架可能会改变而预先支付增加抽象层和复杂性的代价。相反，您应该从 KISS 和 YAGNI 原则开始。如果以后要更改UI框架，那么您只需从头开始重新实现UI层即可。