Comments 18
Круто конечно, но мне кажется тему раскрыл Миша Давыдов в феврале 2012 на Субботнике. Он говорил о песочнице для модулей. Вместо одного хранилища всех событий, возможно стоит создавать экземпляр песочницы для каждой группы модулей. К тому же, насколько я понял, у вас модули могут слушать события друг-друга, что не верно с точки зрения архитектуры.
1. Каждый модуль может только публиковать/слушать свои события
2. Есть песочница которая управляет группой модулей (она же устанавливает связи между их событиями)
3. Песочниц может быть много, в зависимости от масштабов приложения.
Получается что если у меня есть модуль Message, и он публикует Message_show, то это событие может быть только внутри файла Controller_Message, который разруливает все события модулей сообщения, всплывающих окон и т.п. Ну и для других соответственно. Например Controller_Data — точно не должен работать с модулями сообщений и связывает только события связанные с данными.
1. Каждый модуль может только публиковать/слушать свои события
2. Есть песочница которая управляет группой модулей (она же устанавливает связи между их событиями)
3. Песочниц может быть много, в зависимости от масштабов приложения.
Получается что если у меня есть модуль Message, и он публикует Message_show, то это событие может быть только внутри файла Controller_Message, который разруливает все события модулей сообщения, всплывающих окон и т.п. Ну и для других соответственно. Например Controller_Data — точно не должен работать с модулями сообщений и связывает только события связанные с данными.
Действительно, локальные события в модулях не должны выходить за их пределы, и это правильно с точки зрения архитектуры.
Но, во-первых, наш модуль никоим образом не навязывает какой бы то ни было стиль программирования, а всего лишь
является инструментом для анализа уже существующих событий. Т.е. глядя на чужой проект, написанный в таком стиле,
знание о «песочницах» не поможет вам разобраться.
Во-вторых, в приложениях с единой точках входа информации единого медиатора избежать практически нереально.
Примером таких точек входа является общение между встроенными приложениями через их API, принятие информации
по WebSocket'ам и много другое.
Но, во-первых, наш модуль никоим образом не навязывает какой бы то ни было стиль программирования, а всего лишь
является инструментом для анализа уже существующих событий. Т.е. глядя на чужой проект, написанный в таком стиле,
знание о «песочницах» не поможет вам разобраться.
Во-вторых, в приложениях с единой точках входа информации единого медиатора избежать практически нереально.
Примером таких точек входа является общение между встроенными приложениями через их API, принятие информации
по WebSocket'ам и много другое.
Кстати, с одной стороны песочница это крутая штука, но она может превратиться в большой слой бюрократии если постоянно все везде ограничивать. Те когда нужно получать какие-то новые данные приложения приходится добавить этот модуль в песочницу, а потом вызвать его в Модуле. Похоже на антипаттерн Павлик Морозов.
В свою очередь интерфейс CommonJS модулей так же является своеобразной песочницей и эта песочница положительно сказывается на качестве продукта и не вставляет палок в колеса.
В свою очередь интерфейс CommonJS модулей так же является своеобразной песочницей и эта песочница положительно сказывается на качестве продукта и не вставляет палок в колеса.
не навязывает какой бы то ни было стиль программирования
Тогда ещё вопрос. Если у меня синтаксис отличается, например слушатели и события объявляются как-нибудь вот так:
event.listen("something", function(data) {
...
});
event.trigger("something", data);
Есть какой-нибудь функционал, чтобы без гемора и копания в коде начать искать вместо mediator.on / off -> event.listen / trigger?
Модуль capo поддерживает следующие методы для подписки: «on|listen|listenTo|listenToOnce|once|subscribe»,
для триггеров — «trigger|publish|emit». Поиск по этим шаблонам будет происходить по умолчанию, без
дополнительной конфигурации.
Имя же объекта-медиатора указывается опцией (по дефолту «mediator»). Пример для
консоли -o event, для работы через API — метод event:
Плагин поддерживает расширение методов и триггеров через файл конфигурации.
для триггеров — «trigger|publish|emit». Поиск по этим шаблонам будет происходить по умолчанию, без
дополнительной конфигурации.
Имя же объекта-медиатора указывается опцией (по дефолту «mediator»). Пример для
консоли -o event, для работы через API — метод event:
capo(path).event('event')...Плагин поддерживает расширение методов и триггеров через файл конфигурации.
Больше об event-driven архитектуре 6 Марта на Вебинаре от Binary Studio.
По-моему, наследником событий является FRP. Это, по сути, те же самые подписки, но «в другую сторону». Плюс в том, что FRP в коде как раз и выражает (практически дословно) кто на кого подписан.
А описанный вами минус — неопределенность триггеров и подписчиков — по мне вообще является плюсом событийной модели, потому что как раз независимость источника от приёмников события (да и наоборот) как раз постулируется как преимущество подписки в противовес прямому вызову.
А описанный вами минус — неопределенность триггеров и подписчиков — по мне вообще является плюсом событийной модели, потому что как раз независимость источника от приёмников события (да и наоборот) как раз постулируется как преимущество подписки в противовес прямому вызову.
С моей точки зрения и да и нет, поскольку взамен преимуществ слабосвязанной системы мы получаем некоторые сложности при разработке или адаптации на проекте.
Похоже, я вас не понял. Мой поинт в том, что если зависимость есть, то в FRP она будет выражена явно, в виде формулы. В событийной схеме — нет. А зависимости есть всегда. Если в нашей модели компонент Б зависит от компонента А, то в FRP, в коде, мы получим ровно эту зависимость. Это не является сильной связанностью.
мы получаем некоторые сложности при разработке или адаптации на проектеО каких сложностях идёт речь?
FRP это немного другая парадигма, и я не затрагивал ее в своей статье. Она также имеет свои преимущества и недостатки.
Я имел в виду сложность отслеживания ивентов с ростом проекта в событийной модели. Событие триггерится и слушается сразу в нескольких компонентах. Следовательно части кода, отвечающие за это, находятся в разных файлах или и того хуже — проектах. Можно еще представить ситуацию, когда подписка на ивент влечет за собой триггер другого ивента. Исходя из личного опыта, такого рода «цепочки» порой очень трудно отслеживать.
Я имел в виду сложность отслеживания ивентов с ростом проекта в событийной модели. Событие триггерится и слушается сразу в нескольких компонентах. Следовательно части кода, отвечающие за это, находятся в разных файлах или и того хуже — проектах. Можно еще представить ситуацию, когда подписка на ивент влечет за собой триггер другого ивента. Исходя из личного опыта, такого рода «цепочки» порой очень трудно отслеживать.
Скорее даже так: мы получаем сложности, когда система становиться очень большой. Иногда появляются магические баги и трудно понять кто сгенерировал лишнее событие. Автор спасибо, подтолкнул к некоторым идеям по оптимизации. В данный момент, например у меня, очень много такого трудно-читаемого кода:
utils.event.listen("difficulty__update", function (index) {
global.sudoku.difficulty = index;
});
utils.event.listen("helper__click", function () {
utils.event.trigger("board__select_values");
});
utils.event.listen("popup_window__hidden", function () {
utils.event.trigger("main_menu__show");
});\\
utils.event.listen("board__create", function (nodes) {
utils.event.trigger("board_animation__init", nodes);
utils.event.trigger("memory__load");
});
utils.event.listen("splash_screen__hidden", function () {
utils.event.trigger("main_menu__show");
});
UFO just landed and posted this here
на одном проекте юзал похожую библиотеку. называлась PubSub.js. правда, она была без такого инструментария, как в топике.
UFO just landed and posted this here
Sign up to leave a comment.
Продвинутая работа с подписками в еvent-driven архитектуре в JavaScript