Comments 18
что-то мне кажется у вас неправильно с архитектурой раз вам это понадобилось
может привести пример «на кошках»?
может привести пример «на кошках»?
Например, вывод основного дизайна сайта, когда подключаются все имеющиеся модули, в «первом круге» каждый модуль анализирует текущую ситуацию и отправляет заявку на «второй круг», где выигравший модуль и генерирует дизайн
Конкретно эта задача возникала у меня не раз и всегда получалось решить ее очень просто. В частности, в Django, где используется некое подобие MVC, эту логику можно разместить во вьюхе и даже в зависимости от ситуации передавать данные в разные шаблоны.
Зачем так усложнять я тоже понять не могу. Может быть дадите более расширенный пример?
Зачем так усложнять я тоже понять не могу. Может быть дадите более расширенный пример?
Шаблоны динамически подключаемые, о конкретном кол-ве и логике вам не известно, а так шаблон подключается на событие и сам устанавливает приоритет вывода, на самом деле можно много где применить данную модель да и реализуется она достаточно быстро. Вывод дизайна, обработка шаблонных операторов, простые события (добавление пользователя, добавление комментария)…
Вернее модули, конечно же модули =)
Я бы сакцентировал побольше внимания на независимости отдельных обработчиков (то есть, как я понял, на том, что они могут быть частью совершенно разных модулей) и на том, что все это затевается ради приоритезации. Как-то из статьи это не сразу становится понятным, или я что-то упускаю.
Другой вопрос, что я ни разу не сталкивался с такой необходимостью. Поэтому моя первая реакция была та же, что и у @akaBd, то есть подумалось, что что-то не так с дизайном системы.
Другой вопрос, что я ни разу не сталкивался с такой необходимостью. Поэтому моя первая реакция была та же, что и у @akaBd, то есть подумалось, что что-то не так с дизайном системы.
еще раз перечитал… не, без 100 гр че-то не могу понять никак идею…
я 1 сегодня работаю?
я 1 сегодня работаю?
это просто цепочки вызововов с приоритетами? так?
В статье под цепочкой вызовов я понимал возможность писать код, как в jquery $a->start()->right()->step(2)->stop();
А в общем все действительно просто, назначается приоритет, кто даст больше тот и выиграл, просто как то реализовал в своем проекте данную модель, понравилась, решил поделиться, мб кому нибудь тоже пригодится
А в общем все действительно просто, назначается приоритет, кто даст больше тот и выиграл, просто как то реализовал в своем проекте данную модель, понравилась, решил поделиться, мб кому нибудь тоже пригодится
«обработчики анализируя состояние системы выдВигают приоритеты»
Конец статьи, начиная со схемы, действительно сложен для понимания с первого раза. Особенно без конкретного примера.
По ходу чтения возникло пару вопросов:
1. Как поведёт себя система при большом количестве слушателей на одно событие? Я так понимаю, что Вы выводите модульный дизайн с помощью такой хитрой схемы, соответственно одним обработчиком его не вывести, т.е Вы скорее всего используете рекурсивную генерацию событий для каждой части сайта (по крайней мери это было бы логично, раз хочется добиться такой динамики и независимости). Если на каждое событие установлено >10-20 слушателей, и каждому из них даётся время на анализ входящих данных, базовые манипуляции и вынесение решения, то не будет ли такая система «тормозить» при разработке серьёзных и высоконагруженных проектов?
2. При работе слушателей первого круга, не затрагиваются ли какие-либо глобальные параметры системы? Может я просто не до конца проникся сутью, т.к детального примера работы не было, но манипуляции с данными, которые «возможно будут», а «возможно не будут» приняты в дальнейшем необходимо производить внутри какого либо контекста, либо иметь изолированную песочницу, чтобы можно было откатить изменения сделанные предыдущим слушателем первого круга. Возможно это и не нужно, если нет работы с глобальными параметрами системы.
Конец статьи, начиная со схемы, действительно сложен для понимания с первого раза. Особенно без конкретного примера.
По ходу чтения возникло пару вопросов:
1. Как поведёт себя система при большом количестве слушателей на одно событие? Я так понимаю, что Вы выводите модульный дизайн с помощью такой хитрой схемы, соответственно одним обработчиком его не вывести, т.е Вы скорее всего используете рекурсивную генерацию событий для каждой части сайта (по крайней мери это было бы логично, раз хочется добиться такой динамики и независимости). Если на каждое событие установлено >10-20 слушателей, и каждому из них даётся время на анализ входящих данных, базовые манипуляции и вынесение решения, то не будет ли такая система «тормозить» при разработке серьёзных и высоконагруженных проектов?
2. При работе слушателей первого круга, не затрагиваются ли какие-либо глобальные параметры системы? Может я просто не до конца проникся сутью, т.к детального примера работы не было, но манипуляции с данными, которые «возможно будут», а «возможно не будут» приняты в дальнейшем необходимо производить внутри какого либо контекста, либо иметь изолированную песочницу, чтобы можно было откатить изменения сделанные предыдущим слушателем первого круга. Возможно это и не нужно, если нет работы с глобальными параметрами системы.
Спасибо за исправление,
1) В том то и преимущество, что каждый обработчик разделен на две ветки: первый слушатель (именно он анализирует сложившуюся ситуацию и выдвигает приоритет обработки) и второй слушатель (в нем заключен основной функционал обработки события, например в нем генерируется дизайн для страницы). Логично реализовать обработчик «первого круга» как можно легче и все необходимые действия по обработке вынести в обработчик «второго круга». Если данный обработчик не выиграет приоритет на обработку события, то обработчик «второго круга» не выполняется вообще.
Ну и конечно все это надо обрабатывать лишь при изменении внутреннего состояния, а в общем нужно все кешировать в nosql бд
2) В принципе при возникновении событий, где требуется определить главный обработчик, обработчики «первого круга» будут лишь анализировать текущее состояние (в том числе и глобальные переменные), но не вносить какие либо изменения, эту роль может выполнить главный обработчик
1) В том то и преимущество, что каждый обработчик разделен на две ветки: первый слушатель (именно он анализирует сложившуюся ситуацию и выдвигает приоритет обработки) и второй слушатель (в нем заключен основной функционал обработки события, например в нем генерируется дизайн для страницы). Логично реализовать обработчик «первого круга» как можно легче и все необходимые действия по обработке вынести в обработчик «второго круга». Если данный обработчик не выиграет приоритет на обработку события, то обработчик «второго круга» не выполняется вообще.
Ну и конечно все это надо обрабатывать лишь при изменении внутреннего состояния, а в общем нужно все кешировать в nosql бд
2) В принципе при возникновении событий, где требуется определить главный обработчик, обработчики «первого круга» будут лишь анализировать текущее состояние (в том числе и глобальные переменные), но не вносить какие либо изменения, эту роль может выполнить главный обработчик
Спасибо за статью, как-раз этот вопрос актуален (лично для меня), есть над чем поразмыслить :)
При разработке больших приложений/систем пришел к выводу: подход описанный автором, в объемном проекте, намного проще поддерживать.
В одном из последних проектов решил в качестве ядра системы сделать обработчик событий с слушателями и загрузчик модулей, для модулей.
По ходу разработки проекта модули простым образом «вешаются» на ядро и в одну строчку подключаются к системе.
И того:
— единожды разработанное ядро можно применять в разных будущих разработках, подключая/отключая модули
— программист работает только с модулем, требования к разработке модуля можно описать интерфейсом, в результате работа с самым обычным РНР + знать название и функции нескольких методов (важно для поиска новых кадров)
— каждый модуль независимый, но может обращаться к другим модулям через ядро
Из минусов — при сотни событий нужно протестировать расход памяти.
Но сейчас в приоритете элегантность и простота реализации для программиста, с железом проблем нет.
Городить этажные наследования и классы с десятками методов в тысячи строк кода сегодня не круто.
При разработке больших приложений/систем пришел к выводу: подход описанный автором, в объемном проекте, намного проще поддерживать.
В одном из последних проектов решил в качестве ядра системы сделать обработчик событий с слушателями и загрузчик модулей, для модулей.
По ходу разработки проекта модули простым образом «вешаются» на ядро и в одну строчку подключаются к системе.
И того:
— единожды разработанное ядро можно применять в разных будущих разработках, подключая/отключая модули
— программист работает только с модулем, требования к разработке модуля можно описать интерфейсом, в результате работа с самым обычным РНР + знать название и функции нескольких методов (важно для поиска новых кадров)
— каждый модуль независимый, но может обращаться к другим модулям через ядро
Из минусов — при сотни событий нужно протестировать расход памяти.
Но сейчас в приоритете элегантность и простота реализации для программиста, с железом проблем нет.
Городить этажные наследования и классы с десятками методов в тысячи строк кода сегодня не круто.
Спасибо за спасибо =)
Описанное Вами решение очень напоминает описанное Nikolas Zakas'ом в презентации (только он описывает такую архитектуру для JavaScript-приложения):
www.youtube.com/watch?v=vXjVFPosQHw
www.slideshare.net/nzakas/scalable-javascript-application-architecture
www.youtube.com/watch?v=vXjVFPosQHw
www.slideshare.net/nzakas/scalable-javascript-application-architecture
Прямой вызов обработчиков на событие практичен в простых задачах. Если задача чуть более сложна, то важными факторами правильности работы системы оказывается упорядоченность обработчиков. Приоритеты, порядковые номера – камень в модульность системы. Чтобы корректно добавить обработчик, нужно знать о других обработчиках. Правильным решением будет, когда ни обработчик, ни событие не влияют на приоритеты, а процесс обработки построен по цепочке обязанностей – вверх или вниз по иерархии компонентов системы. В Javascript, к примеру, событие нажатия по ссылке движется от самой ссылки по её родителям до документа. В итоге порядок обработки четко соблюдается структурой приложения.
Не совсем понял зачем 2 круга обработки событий и как это работает.
Я когда события делал я все события разделил как во многих cms на 3 типа — событие, фильтр, действие (деление очень условное, это все событие). Событие просто кидает сообщение, обработчики его обрабатывают (каждый следующий обработчик получает результат предыдущего). Фильтр дает на вход значение, обработчики его «фильтруют» и возвращают на выходе отфильтрованное значение. Действие, как и событие, кидает событие, но оно ждет что в итоге что-то вернется инициатору события (событие с присвоением).
Уже 4 года все устраивает и еще не было момента, где бы уперся. Для приложение с очень гибкими требованиями событийная модель достаточно неплохо подходит за основу построения архитектуры на мой взгляд.
Я когда события делал я все события разделил как во многих cms на 3 типа — событие, фильтр, действие (деление очень условное, это все событие). Событие просто кидает сообщение, обработчики его обрабатывают (каждый следующий обработчик получает результат предыдущего). Фильтр дает на вход значение, обработчики его «фильтруют» и возвращают на выходе отфильтрованное значение. Действие, как и событие, кидает событие, но оно ждет что в итоге что-то вернется инициатору события (событие с присвоением).
Уже 4 года все устраивает и еще не было момента, где бы уперся. Для приложение с очень гибкими требованиями событийная модель достаточно неплохо подходит за основу построения архитектуры на мой взгляд.
Sign up to leave a comment.
Многоуровневая модель обработки событий