Здравствуйте, Gattaka, Вы писали:
G>Вы используете event'ы если речь идет не о WinForms и WPF? Как часто, можете привести пример?
В смысле, кроме очевидного NotifyPropertyChanged и не менее очевидных контроллеров / view model? А зачем?
События подразумевают наличие stateful-объектов, т.е. веб сразу идёт лесом. Хелперы? По определению stateless, уведомления делаются через async/IProgress.
Биз-логика обычно накручивается на интерфейсах/делегатах, но никак не на событиях.
Что там осталось, свои фреймворки или плагины к какому-нибудь крупному продукту? Ну и как часто кто-либо их пишет?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Gattaka, Вы писали:
G>>Вы используете event'ы если речь идет не о WinForms и WPF? Как часто, можете привести пример? S>В смысле, кроме очевидного NotifyPropertyChanged и не менее очевидных контроллеров / view model? А зачем?
S>События подразумевают наличие stateful-объектов, т.е. веб сразу идёт лесом. Хелперы? По определению stateless, уведомления делаются через async/IProgress. S>Биз-логика обычно накручивается на интерфейсах/делегатах, но никак не на событиях.
Положим у вас поменялось имя пользователя. Вы поменяли само имя, а также должно еще куча всего сменится — автарка, отправиться письмо в налоговую ( ), военкомат оповестить если мужик, жене имя тоже поменять ну и т.п.
S>Что там осталось, свои фреймворки или плагины к какому-нибудь крупному продукту? Ну и как часто кто-либо их пишет?
Вот и я думаю зачем они нужны. WinForms и WPF тоже без них можно было бы обойтись.
Здравствуйте, Gattaka, Вы писали:
G>Положим у вас поменялось имя пользователя. Вы поменяли само имя, а также должно еще куча всего сменится — автарка, отправиться письмо в налоговую ( ), военкомат оповестить если мужик, жене имя тоже поменять ну и т.п.
Ну так не событиями же всю эту радость накручивать Это т.н. бизнес-транзакция и для её реализации есть куча разных подходов. От extensibility points и до service orchestration.
S>>Что там осталось, свои фреймворки или плагины к какому-нибудь крупному продукту? Ну и как часто кто-либо их пишет? G>Вот и я думаю зачем они нужны.
Как мне кажется, это вопрос из серии "я не использую ассемблер, зачем он нужен?". event-ы — это просто инструмент. Один из многих, предоставляемых шарпом. Если он вам не подходит, далеко не факт, что он не подходит всем
G>WinForms и WPF тоже без них можно было бы обойтись.
Альтернатива-то какая? Реализация врукопашную? Не, ну кому-то и ранняя ява нравится, о вкусах не спорят.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Gattaka, Вы писали:
G>>Вы используете event'ы если речь идет не о WinForms и WPF? Как часто, можете привести пример?
H>Использую. Ровно в тех местах, где уместен "Listener", потому что это оно и есть.
А можете примеры привести. Словестно, с кодом слишком заморочно.
Здравствуйте, Gattaka, Вы писали:
S>>Что там осталось, свои фреймворки или плагины к какому-нибудь крупному продукту? Ну и как часто кто-либо их пишет?
G>Вот и я думаю зачем они нужны. WinForms и WPF тоже без них можно было бы обойтись.
Всякие паттерны типа observer'ов и MVC, которые не обязательно ui, можно проще реализовывать. Это же синтаксический сахар, не более.
Здравствуйте, Gattaka, Вы писали:
G>Вы используете event'ы если речь идет не о WinForms и WPF? Как часто, можете привести пример?
Речь я так понимаю о С# event? В web не используется.
А если говорить о event более широко, то например шаблон publisher-subscriber, тот же Service Bus. Есть event-driven приложения, когда на внешнее воздействие (command) порождает event, обработка которого так же может породить новые event и т.д. Удобно когда заранее не известно кому может потребоваться среагировать на то или иное событие.
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, Gattaka, Вы писали:
G>>Вы используете event'ы если речь идет не о WinForms и WPF? Как часто, можете привести пример?
Doc>Речь я так понимаю о С# event? В web не используется. Doc>А если говорить о event более широко, то например шаблон publisher-subscriber, тот же Service Bus. Есть event-driven приложения, когда на внешнее воздействие (command) порождает event, обработка которого так же может породить новые event и т.д. Удобно когда заранее не известно кому может потребоваться среагировать на то или иное событие.
И как в таких системах решается проблема WeakEventManagment'a?
Здравствуйте, Gattaka, Вы писали:
G>И как в таких системах решается проблема WeakEventManagment'a?
А почему она там должна быть? Между published и subscriber нет прямой связи. Между ними тот же ServiceBus queue (очередь).
Published просто отправляет event в очередь. Далее Subscriber может быть подписан на конкретную очередь (вариант с topic в Azure).
Или же очередь разбирается неким Dispatcher, который создает нужные subscriber. Если для сообщения нет подписчика, то идет запись в журнал а само сообщение помешается в спец. очередь (dead letter queue). А чтобы такое не возникало — есть integrations tests которые проверяют что все события имеют подписчиков.
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, Gattaka, Вы писали:
G>>И как в таких системах решается проблема WeakEventManagment'a?
Doc>А почему она там должна быть? Между published и subscriber нет прямой связи. Между ними тот же ServiceBus queue (очередь).
Блин, ее не может не быть. Она появляется в тот момент когда ты на событие подписываешься. C# здесь какой либо гибкости не предоставляет.
Здравствуйте, Gattaka, Вы писали:
G>Блин, ее не может не быть. Она появляется в тот момент когда ты на событие подписываешься. C# здесь какой либо гибкости не предоставляет.
Ну предлагаю вам найти ее тут. Учитывая что C# event тут не используются. Я же говорил об event как о части паттерна published-subscriber, который может реализован быть не только с использованием ключевого слова C# event
Здравствуйте, Doc, Вы писали:
Doc>Ну предлагаю вам найти ее тут. Учитывая что C# event тут не используются. Я же говорил об event как о части паттерна published-subscriber, который может реализован быть не только с использованием ключевого слова C# event
Ну я так и подумал. Спрашивал как раз про С# event. Какая-то рудиментальная языковая конструкция на самом деле.
Здравствуйте, Gattaka, Вы писали:
G>А можете примеры привести. Словестно, с кодом слишком заморочно.
Код приводить не стану. Идея в развязывании зависимостей: класс А генерирует события, класс Б обрабатывает эти события. Классы А и Б ничего не знают друг о друге. Такой код также можно развязать также через интерфейс (Listener), просто через события код компактнее и не надо интерфейсы придумывать, когда классов вроде А — много, а Б — один.
Это т.н. бизнес-транзакция и для её реализации есть куча разных подходов. От extensibility points и до service orchestration.
Реализация врукопашную? Не, ну кому-то и ранняя ява нравится, о вкусах не спорят.
