Сегодня я хочу рассмотреть один из наиболее распространенных подходов к построению глобальной архитектуры приложения - подход, основанный на генерации и последующей обработке событий. По большому счету, событийную модель можно использовать и для организации некой части приложения (например - обработки транзакций). Но в данной статье буду говорить о приложении в целом.
Большинство приложений в процессе своей работы постоянно реагируют на те или иные события. Это может быть щелчок пользователем по иконке, получение http-запроса, получение сигнала от датчика, завершение коммита транзакции и т.д. Реакция приложения проявляется в выполнении некоторых действий (отрисовка окна, отправка http-ответа, отправка сигнала исполнительному устройству, запуск BPEL-процесса и т.д.). Так вот, суть в том, что никто не мешает перенести такое поведение на уровень архитектуры приложения, т.е. организовав не только его внешнее поведение в соответствии с событийной моделью, но и внутреннее строение.
Кто работал с WinAPI или с Java Swing, тот должен быть хорошо знаком с такой моделью построения программы. В приложении есть некоторые агенты - события, которые генерируются в ответ на внешнее воздействие. Есть обработчики событий - код, который непосредственно делает что-то полезное. И есть то, что сводит гору и Магомета - диспетчер событий. Именно он вызывает те или иные обработчики в ответ на возникновение тех или иных событий.
