Comments 4
На самом деле ценности в gen_event не больше, чем в gen_fsm. Т.е. есть, но редко приходится пользоваться.
Конечно есть, но как только начинаешь ковыряться, возникает куча проблем, прежде всего связанных с невозможностью подписаться в gen_event-е на сообщения от процессов.
Конечно есть, но как только начинаешь ковыряться, возникает куча проблем, прежде всего связанных с невозможностью подписаться в gen_event-е на сообщения от процессов.
А зачем получать сообщения в gen_event? Идеологически это ошибка. Событие уже есть, когда мы попали в gen_event. Больше ничего знать не надо. gen_event очень удобен, когда куче разным процессам необходимо делать какие-то действия при изменении в БД, например. Пишется кучка обработчиков каждый в своем отдельном модуле.
У нас также все логи пишутся через геневенты. Подкинул файл console_logger получил вывод в консоль, подкинул file_logger получил вывод в файл. И так далее db_logger, network_logger…
У нас также все логи пишутся через геневенты. Подкинул файл console_logger получил вывод в консоль, подкинул file_logger получил вывод в файл. И так далее db_logger, network_logger…
Есть такая штука, как Aspect Oriented Programming. Во всех примерах, описывающих эту концепцию, используется пример с журналированием вызовов функции.
Почему-то, основные примеры gen_event тоже выстроены вокруг журналирования.
Пример с транзакциями явно надуман. Проблема с ним в том, что гарантированно завтра же появится необходимость обратной связи. В этом и есть проблема gen_event: он гарантированно не дает обратной связи. И как только появится в ней необходимость, прийдется болезненно перекраивать архитектуру.
Журналирование — пожалуй единственный пример бизнес-логики, где гарантированно не нужна обратная связь.
Почему-то, основные примеры gen_event тоже выстроены вокруг журналирования.
Пример с транзакциями явно надуман. Проблема с ним в том, что гарантированно завтра же появится необходимость обратной связи. В этом и есть проблема gen_event: он гарантированно не дает обратной связи. И как только появится в ней необходимость, прийдется болезненно перекраивать архитектуру.
Журналирование — пожалуй единственный пример бизнес-логики, где гарантированно не нужна обратная связь.
Это почему же пример с БД надуман? Есть модуль который конфигурит кучу параметров, меняя значения в мнезии. На каждую такую запись идет евент {db_set,, }. Любой модуль в системе может подписаться на это дело своим геневентом и сделать что-нить полезное. Причем это полезное очень легко заменяется просто подсовыванием другого файла обработчика. Прелесть этого всего еще и в том, что оно асинхронное. Вызвалось и отработало. Результат своей отработки можно также кинуть еще одному геневенту или дернуть gen_server:cast если так хочется обратной связи. Но на практике этого еще ни разу не понадобилось.
Sign up to leave a comment.
Введение в gen_event: Уведомления об изменениях счета