Распространение событий в проекте на основе коллекции

Единственный способ ответить, влияет ли это на вашу производительность, - это проверить ее: попробуйте один способ, когда вы распространяете события, а затем другой, где вы подключаетесь напрямую. Посмотрите, что быстрее.

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

Я бы порекомендовал ваш подход, если бы кто-нибудь спросил, как делать то, что вам нужно. Продолжайте, если это не проблема.

ИЗМЕНИТЬ

В ответ на ваш комментарий к другому ответу я хотел расширить. События C # имеют так называемый «синтаксис свойств». Если реализовано явно в классе, это выглядит примерно так:

private EventHandler eventDelegate;

public event EventHandler MyEvent
{
    add { eventDelegate += value; }
    remove { eventDelegate -= value; }
}

(На самом деле он использует Delegate.Combine, но здесь это несущественно)

Когда вы присоединяетесь к событию, он фактически вызывает код add, передавая делегат для присоединения как value; то же самое верно и для remove.

Когда вы используете такой сокращенный синтаксис событий:

public event EventHandler MyEvent;

На самом деле он генерирует скрытый код, очень похожий на то, что я опубликовал выше. Однако, если вы сделаете это явным образом, вы сможете делать все, что захотите, в обработчиках add и remove. Это означает, что вы можете перенаправить целевого делегата в другое место. В случае другого ответа он перенаправляет делегата на дочерний объект.

Это будет работать тогда и только тогда, когда выполняются следующие условия:

1. Между родителем и потомком существует соотношение 1: 1, и связанный объект не изменится.
2. Предоставление ссылки на дочерний объект (как object) допустимо

Если у вас несколько дочерних элементов, это технически возможно (вы можете просто выполнить цикл и присоединить ко всем из них в add и удалить их всех в remove), но с этим гораздо труднее справиться. Если связанный объект или набор объектов могут измениться после присоединения события, то координация становится практически невозможной.

Кроме того, если ваши события соответствуют рекомендуемым методикам для событий (где вы передаете объект запуска как sender), то, поскольку вы прикрепляете цель непосредственно к дочернему событию, а не поднимаете его самостоятельно, вы будете выставлять ссылку на дочерний объект через этот аргумент. Понятия не имею, уместно ли это для вас или приемлемо, но это следует учитывать.

Вы можете сделать это в классе System:

event EventHandler FrameEvent
{
    add { this.frame.FrameEvent += value; }
    remove { this.frame.FrameEvent -= value; }
}

Итак, если клиент делает это

system.FrameEvent += Handler;

Обработчик действительно привязан к событию в классе Frame.