Лучшая практика C#: Централизованный контроллер события или нет

Нет никакой сортировки свойств объекта JavaScript и никакого определенного порядка, поддерживаемого существующими поставщиками браузеров, кроме Microsoft IE +.

Это означает, что вы вообще не можете упорядочивать или изменять свойства объекта. Порядок ключей объекта произвольный и не поддерживается в любом случае. Это просто не требование языка, и решение об обслуживании заказа ключей принимается стороной-исполнителем.

6
задан Community 23 May 2017 в 10:27
поделиться

6 ответов

Вы могли поместить само событие в интерфейс, так, чтобы A не должен был знать о C непосредственно, но только что это имеет соответствующее событие. Однако, возможно, Вы подразумеваете, что экземпляр A не имеет вида экземпляра C...

Я попытался бы избегать централизованной системы событий. Это, вероятно, сделает тестирование тяжелее и представленное плотное соединение, как Вы сказали.

Один шаблон, о котором стоит знать, делает событие, проксирующее простой. Если B только выставляет событие для проксирования его к C, можно сделать:

public event FooHandler Foo
{
    add
    {
        c.Foo += value;
    }
    remove
    {
        c.Foo -= value;
    }
}

Тем путем это проксирует подписку/неподписку, а не действие генерирования события. Это оказывает влияние на приемлемость GC, конечно - который может быть выгодным или не, в зависимости от ситуации. Стоящий размышления о все же.

8
ответ дан 8 December 2019 в 13:50
поделиться

Я, вероятно, попытался бы массажировать домен так, чтобы каждый класс мог непосредственно зависеть от соответствующего источника события. То, что я имею в виду, задает вопрос, почему не делают A знают о C? Существует ли, возможно, D, ожидающий для появления?

Как альтернативный подход Вы могли рассмотреть архитектуру брокера события. Это означает, что наблюдатели не знают непосредственно об источнике. Вот интересное видео.

1
ответ дан 8 December 2019 в 13:50
поделиться

То, что Вы могли попробовать, использует посредничество события или NInject или Блока приложений Единицы.

Это позволяет Вам, например:

[Publish("foo://happened")]
public event EventHandler<FooArgs> FooHappened;

[Subscribe("foo://happened")]
public void Foo_Happened(object sender, FooArgs args)
{ }

Если оба объекта будут созданы через контейнер, то события будут подняты трубку автоматически.

6
ответ дан 8 December 2019 в 13:50
поделиться

Это было бы высоко связано, поскольку это должно будет знать каждый класс

Я думаю, что Вы ответили на свой собственный вопрос, если Вы полагаете, что связь плоха! Передающие события через цепочку потенциальных обработчиков являются довольно общим шаблоном во многих средах; Это не может быть самый эффективный подход, но это избегает сложности, которую включил бы Ваш предложенный подход.

Другой подход, который Вы могли проявить, должен использовать диспетчера сообщения. Это включает использование общего формата сообщения (или по крайней мере общего формата заголовка сообщения) для представления событий и затем размещения тех сообщений в очередь. Диспетчер затем берет каждое из тех событий в свою очередь (или на основе некоторого установления приоритетов) и направляет их непосредственно к необходимому обработчику. Каждый обработчик должен быть зарегистрирован в диспетчере при запуске.

Сообщение в этом случае могло просто быть классом с несколькими определенными полями в запуске. Определенное сообщение могло просто быть производной, или Вы могли передать свои определенные для сообщения данные как 'объектный' параметр наряду с заголовком сообщения.

1
ответ дан 8 December 2019 в 13:50
поделиться

Можно проверить объект EventBroker в lib шаблонов и практики M$, если Вы хотите централизованные события.

Лично я думаю, что лучше думает о Вашей архитектуре вместо этого и даже при том, что мы используем EventBroker здесь, ни один из нашего нового кода не использует его, и мы надеемся поэтапно осуществить его один солнечный день.

1
ответ дан 8 December 2019 в 13:50
поделиться

у нас есть своя собственная реализация событийного брокера (с открытым исходным кодом). Учебное заведение: http://sourceforge.net/apps/mediawiki/bbvcommon/index.php?title=Event_Broker

И анализ производительности по адресу: www.planetgeek.ch/2009/07/12/event-broker-performance/

Преимущества по сравнению с САВ: - лучший лесозаготовитель - поддержка расширения - лучшая обработка ошибок - удлиняемые обработчики (пользовательский интерфейс, фоновая нить, ...). и еще кое-что, что я сейчас не могу вспомнить.

Твое здоровье, Урс

0
ответ дан 8 December 2019 в 13:50
поделиться
Другие вопросы по тегам:

Похожие вопросы: