Роль EventBus в GWT

Я читал об этой классной обработке событий в GWT с использованием EventBus, и пока она мне очень нравится. Но я не очень понимаю концепцию, когда я должен ее использовать. Все время? Могу ли я злоупотреблять этим? Должен ли я использовать его для всего, что связано с событиями? (Например, связь между представлением и уровнем презентатора в MVP? Или я могу использовать его с событием onMouseMove? Насколько он тяжеловесен?)

Итак, один вопрос: какова роль EventBus в GWT?


person Croo    schedule 30.11.2011    source источник
comment
Все можно переиграть :-)   -  person jabal    schedule 30.11.2011


Ответы (3)


Я думаю, что использование глобального EventBus для внутренней связи между частями MVP одного виджета является несколько чрезмерным. Это сделало бы ваш виджет зависимым от шины событий. (Если бы шина событий не была в ядре GWT, это было бы более очевидно неприемлемо.) Я рассматриваю шину событий как средство связи между различными виджетами разных частей приложения.

person jabal    schedule 01.12.2011

Вы, наверное, видели эту презентацию Google I/O: Архитектура Google Web Toolkit: лучшая Практика проектирования вашего приложения GWT.

В нем рассматриваются изящные методы, позволяющие сделать работу с большими проектами GWT более управляемой, такие как использование шаблона команд для вызовов RPC, шаблона MVP, внедрения зависимостей и разделения компонентов с использованием шаблона EventBus. В настоящее время существует несколько сред GWT, которые реализуют эти шаблоны (gwt-dispatch для шаблона Command, gwt-presenter и gwt-platform для MVP, GIN & Guice для DI), но что мне нравится в концепции EventBus, так это то, что она является частью базовой структуры GWT (HandlerManager), поэтому мне не нужно добавлять дополнительные зависимости в небольшие проекты GWT.

Я думаю, что концепция EventBus связана с шаблоном проектирования Observer в том смысле, что вы отделяете компоненты View, отвечающие за получение пользовательского ввода, от компонентов Presenter, которые должны быть уведомлены об этих действиях. Дело в том, что ваш 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.

Плохим дизайном было бы вызывать все refresh() методы интересующего компонента в методе onSomethingChange() DateRangePicker вместо запуска события. (Или, что еще хуже: вызов всех методов refresh() в методах onSomethingChange() субкомпонента объекта DateRangePicker.)

person andras    schedule 30.11.2011

Было бы довольно бесполезно использовать это между представлением и презентатором вместо того, чтобы презентер мог напрямую вызывать метод представления.

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

person kgautron    schedule 30.11.2011