Я часто сталкивался с подобной ситуацией при работе с MVC. Мне нравится работать с ним, используя шаблон проектирования посредника в контроллере.
По сути, у вас есть класс, который имеет функцию регистра и функцию уведомления. Функция register принимает объект, который реализует интерфейс слушателя и messageId. Он хранит их в словаре. Функция notify принимает messageId для события, которое необходимо отправить слушателям, и уведомляет соответствующих о том, что событие произошло.
Так что, может быть, что-то вроде
public interface IListener
{
void MessageRaised(int messageId, params object[] arguments);
}
public class Mediator
{
public void Register(IListener listener, int messageId)
{
//... add to dictionary of arrays for each messageId
}
public void NotifyListeners(int messageId, params object[] arguments)
{
//... loop through listeners for the messageId and call the MessageRaised function for each one
}
}
Теперь обычно у меня есть базовый контроллер, и он реализует статический объект-посредник. Тогда все мои другие контроллеры наследуют от него. Если вы используете код и не можете наследовать, вы можете попробовать использовать шаблон синглтона. Статические классы .Net тоже довольно хороши, так как у них есть конструктор, так что вы также можете его использовать.
Так что в вашем случае у меня будет код для каждого элемента управления, реализующего IListener, а затем в конструкторе для каждого будет что-то вроде Mediator.GetInstance (). Register (this, Messages.MyEvent). Это довольно быстрый и грязный способ, который можно немного изменить в будущем, чтобы сделать его более пригодным для повторного использования.
Некоторые ресурсы из быстрого поиска в Google
http://www.avajava.com/tutorials/lessons/mediator-pattern.html
http://sourcemaking.com/design_patterns/mediator
Удачи