Паттерн «обозреватель»

[MiksIr]

При использовании декоратора обозревателя (чистого или event паттерн) нам приходится создавать наблюдателя даже если он в текущем запросе использован не будет. Можно, конечно, использовать прокси - подписывать его, а в случае события - прокси создаст кого нужно, но это если наблюдатель тяжелый.
Кто-то как-то решает этот вопрос? На своей практике использовал глобальный наблюдатель, типа аналога реестра, а конкретные наблюдатели прописаны в конфиге. Но как-то не очень нравится такой вариант.

 

[Вурдалак]

чистого или event паттерн

Че?

Я не понял при чем тут декоратор, если ты про lazy load для подписчиков в observer/mediator, то, например, так: http://symfony.com/doc/current/components/event_dispatcher/container_aware_dispatcher.html Грязновато, но как-то пофиг, это под капотом и даёт существенный профит.

 

[MiksIr]

А, блин, спал мало явно =( Про обозреватель я, конечно. Еще и в теме написал, поправьте у кого права есть.

 

[флоппик]

fixed

 

[MiksIr]

Я правильно понимаю, что там контейнер, который конфигурируется - какой объект на какое событие нужен и который является observer для всех генерируемых событий?

 

[Вурдалак]

Контейнер там — это DIC. DIC знает про конфигурацию, он знает как сконфигурированы твои наблюдатели (слушатели, подписчики и т.п. — в данном контексте это синонимы), поэтому логично, что они описываются в нём же: http://symfony.com/doc/current/cookbook/service_container/event_listener.html

Если углубляться в терминологию, то event dispatcher в Symfony — это больше Mediator, а каждый слушатель/подписчик — это Colleague/Component, если следовать этой терминологии: http://en.wikipedia.org/wiki/Mediator_pattern ContainerAwareEventDispatcher — это декоратор EventDispatcher, который подгружает подписчиков в runtime по мере появления для них событий.

Вообще бросай писать велосипеды, бери Symfiny DIC и Event Dispatcher, это можно встроить в любой legacy-проект при желании, это очень удобно.

 

[Redjik]

Че?

Я не понял при чем тут декоратор, если ты про lazy load для подписчиков в observer/mediator, то, например, так: http://symfony.com/doc/current/components/event_dispatcher/container_aware_dispatcher.html Грязновато, но как-то пофиг, это под капотом и даёт существенный профит.

там pub-sub же, хотя разница с observer мизерна

 

[MiksIr]

Вообще бросай писать велосипеды, бери Symfiny DIC и Event Dispatcher, это можно встроить в любой legacy-проект при желании, это очень удобно.

Да вот никак не дойдут руки серьезно до Симфони. Задач таких нет, все больше уровня yii, а с текущей экономической ситуацией, глядишь, и про битрикс придется вспомнить =/
Но доберусь, куда без этого.

 

[MiksIr]

там pub-sub же, хотя разница с observer мизерна

Ну чистый обозреватель (тупо событие "я изменился"), как я понимаю, вообще мало кто использует.

 

[Redjik]

Я вот сейчас парня с USA отговариваю от Yii2, хотя его вполне хватит на проект, просто я ему с берега сразу сказал, что архитектура сомнительная и все спецы в раше, тяжело будет с поддержкой, если я пропаду.
Yii же в основном в России популярен, на западе Laravel в тренде.

 

[whirlwind]

Можно поподробннее? А то не врубаюсь о чем речь. По моему это какой-то неправильный обсервер. Самые правильные ивенты это в C#. Только заразы не first-class и не позволяют спецификацию sync/async. А правильный самописный имхо которые через EventType подписывается. А если через диспетчер подписываться это уже messaging queue какое то. Но мож я чего не понял.

 

[WMix]

видать не понял, диспечер просто рулит подпиской на эвенты, и вызовом подписчиков, а message-queue чаще чтоб добиться асинхронности. в данном случае все синхронно но о разделении логики идет речь.