Привет всем.

Не могу сварганить архитектуру. Укажите на минусы плюсы и возможные пути реализации

Есть класс назвоем его EventManager.
1 Класс должен увидеть новый ивент и отправить его всем подписчикам. После того как отправил и событие обработалось должен вернуться статус обработки, который ядолжен записать в базу напротив ивента(типа событие обработано). Предположительно поставлю этот статус в какое нить поле в eventargs и по возвращении в класс EventManager запишу его в базу.
Вопрос: у меня будет один подписчик,который реально что-то сделает с ивентом и поставит ему статус. В случае если у меня будет два подписчика и оба поменяют статус, то в базу запишется последний, так? Что-то как-то криво выглядит...


2 Есть класс SubscirberNumber1
В нем реализована ОДИНАКОВАЯ логика обработки этого ивента.
Следствием обработки данного события должно быть:
1. Статус обработки (который я запишу в EventArgs)
2. Некий текст, который должен быть отправлен куда-то дальше FooGate.Insert(text)
3. логика обработки этого ивента предполагает что нужно будет выполнить еще ряд действий.


3 Есть класс SubscirberNumber2
В нем реализована ОДИНАКОВАЯ логика обработки этого ивента.
Следствием обработки данного события должно быть:
1. Статус обработки (который я запишу в EventArgs)
2. Некий текст, который должен быть отправлен куда-то дальше BarGate.Insert(text)
3. логика обработки этого ивента предполагает что нужно будет выполнить еще ряд действий.


4 Есть класс SubscirberNumber3
В нем реализована ДРУГАЯ ЛОГИКА обработки этого ивента.
Следствием обработки данного события должно быть:
1. Статус обработки (который я запишу в EventArgs)
2. Некий текст, который должен быть отправлен куда-то дальше FooGate1.Insert(text)
3. логика обработки этого ивента предполагает, что нужно будет выполнить еще ряд действий.


Корчое идея такая:
в первых двух подписчкиах логика обработки одинаковая, в треьем иная. Эту логику не хотелось бы повторять, потому что она гигантская. Да ине хорошо это!
Пункт 1 у всех подписчиков одинаковый.
Пункт 2 у всех разный, в какой гейт пихнуть текст в принципе знает EventManager
где нужно пихать этот текст? Если в EventManager, то нужно вернуть этот текст(полагаю посредством EventArgs), если в самом подписчике, то ему нужно знать куда ему пихать этот текст.
Пункт 3 у всех подписчиков одинаковый, но опять же эти действия можно вызвать непосредственно из подписчиков, а можно и из EventManager



Короче вот я запутался!

Здравствуйте, lumf, Вы писали:

L>Не могу сварганить архитектуру. Укажите на минусы плюсы и возможные пути реализации

На мой взгляд, следует подумать над тем, почему Subscriber1 и Subscriber2 имеют одинаковую логику обработки события. Нельзя ли эту логику делегировать одному подписчику?

Кроме того, непонятно, что система делает и для чего она нужна. Зачем все эти EventManager'ы и Subscriber'ы?

Здравствуйте, lumf, Вы писали:

L>Короче вот я запутался!

Я думаю, стоит ограничится одним обработчиком на каждый тип события. Если удастся этого достигнуть, то примерьте Chain of Responsibility.

Здравствуйте, lumf, Вы писали:

L>Привет всем.

Тому что ты называешь ивентом, больше подходит название "сообщение". А для решения задачи — паттерн Chain of Responsibility. Суть в том что создается цепочка обработчиков сообщения. Сообщение передается первому обработчику, он что-то с ним делает и передает сообщение следующему, и т.д. пока не сообщение не достигнет конца цепочки.
Внятное описание паттерна на C# есть здесь