Сообщение Re[2]: Образцово-показательный интерфейс для EventBus от 23.11.2021 16:43
Изменено 23.11.2021 16:44 Shmj
Re[2]: Образцово-показательный интерфейс для EventBus
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Стейтфул? Фу, бяка.
Кмк, в вашей реализации будет некий словарь, с помощью которого вы сопоставите eventCode и eventHandler. По сути это состояние и оно необходимо — а значит не нужно так его демонстративно избегать. У меня сразу ясно — объект имеет состояние. И это по крайней мере честно.
S>>3. Спорный момент — подтверждение сделано явным в виде отдельного метода.
НС>Отличные грабли. Забыл метод позвать и привет многократные обработки одного события и бесконечно растущая очередь.
А что если не забыл — а не захотел?
S>>Что используете вы?
НС>[c#]
НС>public interface IEventPublisher
НС>{
НС> Task PublishAsync(
НС> Uri source,
НС> string eventCode,
НС> object payload,
НС> IDictionary<string, object>? headers = null,
НС> PublishEventParameters? parameters = null,
НС> CancellationToken cancellation = default);
НС>}
НС>public interface IEventSubscriber
НС>{
НС> // IMPORTANT: dispose the returned result to stop the subscription.
НС> // cancellation WILL NOT cancel the subscription after subscribe completion.
НС> // IMPORTANT: use parameters.SubscriptionFailedCallback to handle non-recoverable subscription failures.
НС> [MustUseReturnValue]
НС> Task<IAsyncDisposable> SubscribeAsync(
НС> Uri source,
НС> string? eventCode,
НС> Type payloadType,
НС> [InstantHandle] Func<EventMessage, CancellationToken, Task> eventHandler,
НС> EventSubscriptionParameters? subscriptionParameters = null,
НС> CancellationToken cancellation = default);
У вас есть плюс, в сравнении с версией eShopOnContainers — не нужно для каждой подписки создавать отдельный объект-обработчик.
НС>Стейтфул? Фу, бяка.
Кмк, в вашей реализации будет некий словарь, с помощью которого вы сопоставите eventCode и eventHandler. По сути это состояние и оно необходимо — а значит не нужно так его демонстративно избегать. У меня сразу ясно — объект имеет состояние. И это по крайней мере честно.
S>>3. Спорный момент — подтверждение сделано явным в виде отдельного метода.
НС>Отличные грабли. Забыл метод позвать и привет многократные обработки одного события и бесконечно растущая очередь.
А что если не забыл — а не захотел?
S>>Что используете вы?
НС>[c#]
НС>public interface IEventPublisher
НС>{
НС> Task PublishAsync(
НС> Uri source,
НС> string eventCode,
НС> object payload,
НС> IDictionary<string, object>? headers = null,
НС> PublishEventParameters? parameters = null,
НС> CancellationToken cancellation = default);
НС>}
НС>public interface IEventSubscriber
НС>{
НС> // IMPORTANT: dispose the returned result to stop the subscription.
НС> // cancellation WILL NOT cancel the subscription after subscribe completion.
НС> // IMPORTANT: use parameters.SubscriptionFailedCallback to handle non-recoverable subscription failures.
НС> [MustUseReturnValue]
НС> Task<IAsyncDisposable> SubscribeAsync(
НС> Uri source,
НС> string? eventCode,
НС> Type payloadType,
НС> [InstantHandle] Func<EventMessage, CancellationToken, Task> eventHandler,
НС> EventSubscriptionParameters? subscriptionParameters = null,
НС> CancellationToken cancellation = default);
У вас есть плюс, в сравнении с версией eShopOnContainers — не нужно для каждой подписки создавать отдельный объект-обработчик.
Re[2]: Образцово-показательный интерфейс для EventBus
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Стейтфул? Фу, бяка.
Кмк, в вашей реализации будет некий словарь, с помощью которого вы сопоставите eventCode и eventHandler. По сути это состояние и оно необходимо — а значит не нужно так его демонстративно избегать. У меня сразу ясно — объект имеет состояние. И это по крайней мере честно.
S>>3. Спорный момент — подтверждение сделано явным в виде отдельного метода.
НС>Отличные грабли. Забыл метод позвать и привет многократные обработки одного события и бесконечно растущая очередь.
А что если не забыл — а не захотел?
S>>Что используете вы?
У вас есть плюс, в сравнении с версией eShopOnContainers — не нужно для каждой подписки создавать отдельный объект-обработчик.
НС>Стейтфул? Фу, бяка.
Кмк, в вашей реализации будет некий словарь, с помощью которого вы сопоставите eventCode и eventHandler. По сути это состояние и оно необходимо — а значит не нужно так его демонстративно избегать. У меня сразу ясно — объект имеет состояние. И это по крайней мере честно.
S>>3. Спорный момент — подтверждение сделано явным в виде отдельного метода.
НС>Отличные грабли. Забыл метод позвать и привет многократные обработки одного события и бесконечно растущая очередь.
А что если не забыл — а не захотел?
S>>Что используете вы?
Скрытый текст | |
НС>public interface IEventSubscriber НС>{ НС> // IMPORTANT: dispose the returned result to stop the subscription. НС> // cancellation WILL NOT cancel the subscription after subscribe completion. НС> // IMPORTANT: use parameters.SubscriptionFailedCallback to handle non-recoverable subscription failures. НС> [MustUseReturnValue] НС> Task<IAsyncDisposable> SubscribeAsync( НС> Uri source, НС> string? eventCode, НС> Type payloadType, НС> [InstantHandle] Func<EventMessage, CancellationToken, Task> eventHandler, НС> EventSubscriptionParameters? subscriptionParameters = null, НС> CancellationToken cancellation = default); | |
У вас есть плюс, в сравнении с версией eShopOnContainers — не нужно для каждой подписки создавать отдельный объект-обработчик.