Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Дело именно в причине, так как именно причина отмены ответит на вопрос как это все инициировать и откуда всять токен.
Вот вы сделали Dispose для подписки — а отменится ли автоматом исполнение уже запущенного eventHandler?
S>>- а в том, как вы его будете отменять, если CancellationToken находится во владении nativeClient, а не передается вами?
НС>Например так.
И к чему линковать будем?
S>>И как это реализовано в интерфейсах? НС>Зачем это реализовывать в интерфейсах? Это особенность реализации. А в интерфейсах есть универсальный CancellationToken.
Почему вы называете его универсальным, если он он не отменяет eventHandler?
Re[17]: Образцово-показательный интерфейс для EventBus
Здравствуйте, Shmj, Вы писали:
НС>>Дело именно в причине, так как именно причина отмены ответит на вопрос как это все инициировать и откуда всять токен. S>Вот вы сделали Dispose для подписки — а отменится ли автоматом исполнение уже запущенного eventHandler?
Непонятен вопрос. Как тебе надо, так и сделай.
S>>>- а в том, как вы его будете отменять, если CancellationToken находится во владении nativeClient, а не передается вами? НС>>Например так. S>И к чему линковать будем?
К оригинальному токену.
S>>>И как это реализовано в интерфейсах? НС>>Зачем это реализовывать в интерфейсах? Это особенность реализации. А в интерфейсах есть универсальный CancellationToken. S>Почему вы называете его универсальным, если он он не отменяет eventHandler?
Потому что он универсальный. А почему он должен отменять eventHandler?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: Образцово-показательный интерфейс для EventBus
Здравствуйте, Shmj, Вы писали:
S>И еще вопрос. Вы внутри метода SubscribeAsync, очевидно, вызываете подтверждение обработки события. Так? У меня это отдельный метод.
По идее за это брокер должен отвечать -- если сообщение принято подписчиком и нет исключения, то считаем что оно вообще
успешно принято. Как минимум с тз брокера.
Кодом людям нужно помогать!
Re[4]: Образцово-показательный интерфейс для EventBus
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Vladek, Вы писали:
V>>Для меня эти проекты от dotnet-architecture — хороший пример того, как делать не надо. Там нет ничего, кроме говнокода.
S>Давайте свой IEventBus — обкашляем.
Раньше были какие-то зачатки, я вроде бы использовал это с MVVM: https://github.com/vborovikov/vividkit/blob/master/src/Core/VividKit/RequestModel/Infrastructure/DefaultEventDispatcher.cs — идея была в том, что один компонент использовал диспетчер для публикации событий, а любой другой компонент, заинтересованный в этом событии, должен был реализовать обработчик события. И диспетчер автомагически выполнял функции медиатора между компонентами. Один диспетчер можно вкладывать в другой, и строить на этом дополнительную логику — но я оставил это пока на будущее, когда реально понадобится.
На данный момент я использую только CQRS: https://github.com/vborovikov/relay/blob/master/src/Relay/RequestModel/IRequestDispatcher.cs — в основном в UI — этот интерфейс удачно встраивается в контроллеры ASP.NET MVC, модели вида MVVM (класс Presenter в том же проекте), консольные приложения, использующие System.CommandLine, и даже недавно использовал его для отправки и получения команд и запросов через MSMQ. Это интерфейс позволяет мне ядро приложения надёжно изолировать от UI каким бы он не был. Именно такой API меня устраивает — минимум методов и всяких ритуалов вокруг них.
Re[5]: Образцово-показательный интерфейс для EventBus
Здравствуйте, Sharov, Вы писали:
S>>>А почему стейтфул? НС>>Потому что нет параметра кого подписываем. S>Т.е. реализация обработки будет в самом подписчике?
Это вопрос к ТС.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[6]: Образцово-показательный интерфейс для EventBus
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Т.е. реализация обработки будет в самом подписчике? НС>Это вопрос к ТС.
Не совсем, я не про детали, а про идею. Stateful потому что обработчик будет назначен через конструктор или
setter? Т.е. это ненужная связанность для подписчика (реализация IEventBus), так?
Кодом людям нужно помогать!
Re[7]: Образцово-показательный интерфейс для EventBus
Здравствуйте, Sharov, Вы писали:
S>>>Т.е. реализация обработки будет в самом подписчике? НС>>Это вопрос к ТС. S>Не совсем, я не про детали, а про идею.
Все равно не ко мне — не я этот интерфейс выдумал.
S> Stateful потому что обработчик будет назначен через конструктор или S>setter?
Стейтфул потому что если у метода нет параметров и возвращаемого значения, то единственный способ сделать с его помощью что то полезное — поменять стейт.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[8]: Образцово-показательный интерфейс для EventBus
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> Stateful потому что обработчик будет назначен через конструктор или S>>setter? НС>Стейтфул потому что если у метода нет параметров и возвращаемого значения, то единственный способ сделать с его помощью что то полезное — поменять стейт.
Там отличие только в параметре типа обработчика, и сразу stateful?
ТС
Task SubscribeAsync<TEvent>()
where TEvent : IntegrationEvent;
исходный
void Subscribe<T, TH>()
where T : IntegrationEvent
where TH : IIntegrationEventHandler<T>;
Или критиковались сразу оба варианта? Просто я не понял как наличие или отсутствие параметра типа
влияет на состояние?
Кодом людям нужно помогать!
Re[8]: Образцово-показательный интерфейс для EventBus
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Стейтфул потому что если у метода нет параметров и возвращаемого значения, то единственный способ сделать с его помощью что то полезное — поменять стейт.
Можно полюбопытствовать — занимаетесь ли разработкой архитектуры? Просто не каждый же сразу обратит внимание.
Re[9]: Образцово-показательный интерфейс для EventBus
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Можно полюбопытствовать — занимаетесь ли разработкой архитектуры? НС>Почти каждый рабочий день. У меня, собственно, две основные обязанности — архитектура и качество кода.
Могли бы порекомендовать какую-нибудь литературу, которая вам помогла?
Re[11]: Образцово-показательный интерфейс для EventBus
