Notifications

События излучаются из объектов DOM или любого использованного Frontend фреймворка, предоставляющего UI компоненты, если конечное приложение работает в браузере; или же Событие может излучаються из лююбого доступного канала связи, шины данных или UNIX-сокета, если приложение работает на платформе NodeJS.

Событие отлавливается Конкретным Медиатором в составе приложения, который выступает посредником между внешним миром и "черным ящиком" приложения, Медиатор не обрабатывает Событие смостоятельно, он отсылает Оповещение об этом Событии подписанной на это Оповещение Команде.

Оповещения рассылаются Фасадом и Прокси; слушаются и отсылаются Медиаторами; отправляются Командам, которые так же могут отправить следующее Оповещение заинтересованным Наблюдателям. Это механизм публикации/подписки, посредством которого многие Наблюдатели (Observers) могут получать и обрабатывать одно и тоже Оповещение.

Оповещения могут иметь, если нужно, «тело», любой объект JavaScript.

В отличии от событий DOM или NodeJS's Events, создание специализированных классов Оповещений, требуется редко, потому может быть использовано прямо «из коробки». Вы можете, конечно, создавать специализированные классы Оповещений для строгой типизации при взаимодействии с ними, но, нужно соизмерять преимущества проверки времени компиляции (в частности для Оповещений) и накладных расходов по поддержки множественных классов Оповещений, так что это, скорее, вопрос стиля программирования.

Оповещения также имеют опциональный «тип», который моет быть использован получателем для классификации.

Например, в приложении редактора документов, это может быть экземпляр Прокси для каждого документа, который открыт, и соответствующий Медиатор для компонента Представления, используемый для редактирования документа. Прокси и Медиатор могут совместно использовать уникальные ключ, который Прокси передаст как тип Оповещения.

Все экземпляры Медиаторов регистрируются для перехвата Оповещений от Прокси, используя тип Оповещения для принятия решения о его обработке.

Мы видим, что конкретный Фасад это хорошее место для определения общего в приложении, констант Оповещений. Поскольку это центральный механизм для взаимодействий с системой, все подписавшиеся на оповещения будут по умолчанию взаимодействовать с Фасадом.

Иногда для этих целей вместо определения констант в Фасаде приложения используется отдельный класс “Констант Приложения”, в случае если эти константы должны быть доступны другому приложению.

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

Однако не следует определять имена Событий в конкретном фасаде. Определите их как статичные константы классов, которые их вызывают, или же в случае кастомных Событий, внутри классов этих Событий.

Реализации частей Приложения, компонентов Представления и Объектов Данных могут оставаться многократно используемыми, если они взаимодействуют со связанными Медиаторами и Прокси не через вызовы методов а через отсылку Оповещений.

Если компонент Представления либо Объект Данных вещает Оповещение в котором заинтересован Медиатор или Прокси, то знание имени этого события нужно только этой паре, всё остальное взаимодействие между слушателем и остальной частью PureMVC приложения может быть организовано посредством Оповещений.

Несмотря на то, что отношения этих взаимодействующих пар (Медиатор/Представление и Прокси/Объект Данных) довольно близки, они остаются «слабо связанными» с остальными частями приложения; при желании модифицировать пользовательский интерфейс либо модель данных могут быть легко подвергнуты рефакторингу.