MVP :: event bus pattern instead of listener

This question is more about the paradigm. Why don't we use Event Bus instead of listeners in an MVP environment? Typically, the “P” part is dependent on references and model references. I am sure that this has the advantage of explicitly concluding a contract between the presentation and the model with the help of the presenter, which is more readable.

However, it would not be a cleaner approach for the host to listen to events from representations and events that carry a payload of the form (for example: json representation). The same thing happens with the host, who refers to the viewing. The view will listen to events from the presenter. The main advantage is that we do not need to write interfaces for each contract between the presentation and the presenter. If you look at the code , you will see that the host accesses the viewing details, such as text fields, which, in my opinion, increase the connection between the presentation and the presenter. Say, if I replace the JavaFx front-end instead of Vaadin, I will also have to change the presenter.

This class is an example from a live project. Here we have different types of events, i.e. I do not create an event class for different cases. For example: LoginViewEvent, DashBoardEvent, etc., Which, in my opinion, are a pain in maintenance.

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;
        }
    }

}

Simple enough, a view dispatches an event DOCUMENT_EDIT_COMPLETE . The presenter layer handles this event. I found this way, the best way to separate the views from the lead.

    @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;
        }
    }

Advantage

  • Less boiler plate code, for n-types we do not need n-interfaces
  • A new event means adding an event element to the listing and updating the corresponding Sign methods of handling this event.

Disadvantage

  • Memory leak if we forget to unregister from eventbus (we encountered it a lot of time)

Questions

1). , . -?

2) , Event Bus, - -?

. , , , ​​ .

+4
1

1) , , . -?

, . int enum Interface s.

, , . . , , Microsoft Win32 API MFC.

, Annotation, . Apache Wicket.

2) , Event Bus, - -?

. Java- - . , , Swing Android.

React Javascript. Model-View-Presenter Flux. , .

JavaFx Vaadin . , , , . , . KISS YAGNI. , .

+2

Source: https://habr.com/ru/post/1611562/


All Articles