MVP :: 事件总线模式而不是监听器

Question

这道题更偏范式。为什么我们不在 MVP 环境中使用事件总线而不是侦听器？通常，"P" 部分具有视图和模型引用的依赖注入。当然，这有一个优势，即通过 Presenter 显示视图和模型之间的显式契约，更具可读性。

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

此 class 是来自实时项目的示例。这里我们有不同类型的事件，即我不为不同的情况创建事件 class。例如： 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;
        }
    }

}

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

    @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) 正如我们看到的那样，它广泛使用了事件总线，有什么缺点吗？使用总线系统而不是接口监听器模式？

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

Answer 1

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

如果有很多事件，您需要很多事件标识符。它们可以是简单的 ints 或 enums 或 Interfaces.

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

为例

在一些项目中，我看到了使用 Annotations 实现的事件拦截器，它提供了一种处理事件的优雅方式。上一次是在项目中使用了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 世界中，使用监听器接口是事实上的标准。以 Swing 和 Android 为例。

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

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

MVP :: 事件总线模式而不是监听器

MVP : : Event Bus pattern instead of Listener

c++

java

design-patterns

vaadin

guava