GWT MVP: HandlerManager EventHandler против GUI EventHandler

Я использую GWT MVP для разработки приложения. Я видел, что у нас может быть два типа обработчиков событий в коде GWT MVP, но я не очень уверен, какой из них мне следует использовать в каком месте:

1) HandlerManager (eventBus) Обработчики событий (например, EditEventHandler ниже) в AppController:

eventBus.addHandler(EditEvent.TYPE,
      new EditEventHandler() {
        public void onEdit(EditEvent event) {
          doEdit(event.getId()); // this would open a new screen, call AsyncService etc
        }
      });

Я понимаю, что такие обработчики событий используются для обработки настраиваемых событий в масштабе всего приложения.

2) Обработчики событий GUI / View (например, ClickHandler) в Presenter, где я обрабатываю событие GUI, а затем запускаю событие приложения, чтобы вызвать его обработчик, как показано ниже:

display.getList().addClickHandler(new ClickHandler() {
    public void onClick(ClickEvent event) {
      int selectedRow = display.getClickedRow(event);

      if (selectedRow >= 0) {
        String id = myDetails.get(selectedRow).getId();
        eventBus.fireEvent(new EditEvent(id)); // this in turn would invoke the EditEventHandler above
      }
    }
  });

Теперь мои вопросы:

1) Почему нам нужно писать EventHandler для событий приложения (например, EditEvent), а не добавлять этот код непосредственно в связанный обработчик событий графического интерфейса (например, addClickHandler)?

2) Разве мы не можем написать код для открытия нового экрана, вызова AsyncService и т. Д. Непосредственно в методе GUI EventHandler, например onClick?

3) Разве это не сделает ваш код более читабельным, поскольку инициируемое событие и работа, которую необходимо выполнить, находятся в одном месте, т.е.Presenter, и вам не нужно переключаться между вашим Presenter кодом и AppController код?


person Pat    schedule 09.08.2014    source источник


Ответы (1)


  1. Вы могли бы это сделать, и в небольших приложениях это, вероятно, будет правильным подходом. Однако вы определенно увеличите взаимосвязь между вашим графическим интерфейсом, бизнес-логикой и различными компонентами. Вы должны представлять свои экраны как независимые блоки и избегать какой-либо связи между этими блоками. В лучшем случае ваш экран, на котором отображается список записей, не должен ничего знать о других экранах или любых других компонентах. Он должен заботиться только об этих записях.
  2. Технически нет причин, по которым вы не можете вызвать AsyncService в своем GUI EventHandler. Просто убедитесь, что вы делаете это в своем Presenter, а не в своем View. Однако чем сложнее ваше приложение, тем сложнее может быть этот подход. У вас будет много вызовов AsyncService, разбросанных по разным Presenters. Возможно, лучше сгруппировать их в вашем AppController, чтобы было 1.) одно место для поиска и 2.) вы могли легко протестировать / имитировать все AsyncService вызовы в вашем AppController.
  3. Работа, которую можно выполнить внутри Presenter, также должна выполняться там без необходимости проходить AppController и обратно. Однако все же имеет смысл поместить AsyncService вызовы в ваш AppController, потому что вам может потребоваться некоторое ведение бухгалтерского учета (например, кеширование результатов в LocalStroage, отправка других событий и т. Д.) И / или уведомление других экранов / компонентов о загруженных данных.

Думайте о событиях как о сообщениях. Вот пример:
У вас есть пара View / Presenter для отображения списка записей (например, RecordListPresenter). Пользователь нажимает кнопку редактирования на одной из записей, и у вас есть отдельная пара View / Presenter для редактирования конкретной записи (например, RecordEditPresenter). Вместо ссылки из вашего RecordListPresenter на ваш RecordEditPresenter, которая позволит им узнать друг друга и увеличить связь, RecordListPresenter отправляет сообщение для редактирования записи (событие Edit). AppController будет действовать как Посредник и открывать, загружать данные и открывать RecordEditEditor (он также может только запустить Событие с загруженными данными, и RecordEditEditor может проявить себя).
Но теперь представьте, что у вас также есть HeaderPresenter для отображения некоторой информации о хлебных крошках (например, какую запись он редактирует). Если вы выберете «бессобытийный» подход, вам понадобится еще одна ссылка в RecordListPresenter и RecordEditPresenter на него, чтобы управлять им. С Events этим Presenters не нужно знать, что есть HeaderPresenter. Они просто запускают События.

Теперь в сложном приложении у вас может быть много таких независимых модулей.

person Ümit    schedule 10.08.2014
comment
поэтому, как правило, мы должны использовать сообщения о событиях (например, Edit event), когда один докладчик хочет вызвать другого докладчика, чтобы докладчики оставались отделенными друг от друга. Есть ли другой сценарий, в котором эти event messages должны быть предпочтительнее написания кода в обработчиках событий графического интерфейса? - person Pat; 11.08.2014
comment
Ну, это применимо ко всему, где вам может потребоваться уведомить несколько компонентов (не обязательно Presenters) о некоторых интересных изменениях. Обработчик событий GUI должен содержать только те вещи, которые актуальны только в контексте этого _2 _ / _ 3_ - person Ümit; 13.08.2014