Шина или слушатели / делегаты в клиентском приложении Swing?

Question

Создание клиентского приложения Swing, о чем следует уведомлять по шине (система сообщений всего приложения, похожая по концепции на JMS, но намного более простая) и о чем следует уведомлять, используя прямые прослушиватели?

Когда я пользуюсь автобусом, у меня всегда возникает ощущение, что «я понятия не имею, кто и где это использует». Кроме того, нет установленного порядка, трудно наложить вето на события, трудно точно знать, что происходит в установленное время.

С другой стороны, использование слушателей означает либо прямую ссылку на исходный объект (связывание), либо передачу ссылки через множество преобразований (A - b_listener -> B, B - c_listener -> C только потому, что необходимо знаю что-то, что только C может сказать, но B не интересуется).

Итак, есть ли какое-то эмпирическое правило по этому поводу? Любое предложение, как сбалансировать?

Answer 1

По моему опыту, пытаться заставить Swing делать то, для чего он не был предназначен или не хочет, чтобы вы это делали, чрезвычайно болезненно.

Я бы пошел с самой простой вещью, которая работала бы; держите ваш код в чистоте, делайте это "Swing Way", пока не начнете видеть проблемы.

Answer 2

Шины событий - очень и очень полезный инструмент для обеспечения развязки в определенных архитектурах. Слушатели просты в реализации, но они имеют значительные ограничения, когда ваш объект и граф зависимостей становятся большими. Слушатели, как правило, сталкиваются с проблемами с циклическими зависимостями (события могут «подпрыгивать» странным образом, и вам приходится играть в игры, чтобы не застревать. Большинство связывающих фреймворков делают это за вас, но есть что-то неприятное в этом зная, что события слушателя разлетаются в миллион мест).

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

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

Answer 3

Соглашение в Java Swing заключается в интенсивном использовании слушателей. Соблюдение соглашения улучшает ремонтопригодность, но подавляет инновации.

Я не сталкивался с автобусным подходом в Swing, но мне это интересно.

Answer 4

Хорошо, я могу представить подход, при котором модели обновляются с использованием системы, подобной BUS, а события из моделей делегируются с использованием слушателей. Простой сценарий: я получил серверную часть, которая представляет производителя данных. Затем на стороне клиента получается пользовательский интерфейс, который потребляет все входящие сообщения и преобразует их в мои внутренние сообщения / DTO и помещает их в шину, которая распределяет их в модели приложений. Эти модели обрабатывают входящие сообщения и решают уведомлять заинтересованные компоненты с помощью прослушивателей.