ASP.NET - разделение интересов

Question

Представьте себе следующий сценарий - у нас есть Page1, которая содержит элементы управления Control A и Control B.

Скажите, что у Control A есть кнопка, и при нажатии этой кнопки мы хотим, чтобы Control B реагировал. Но мы хотим сделать это абстрактно, то есть у нас не может быть, чтобы Control B ничего не знал о Control A, и наоборот.

Таким образом, мы можем разработать эти элементы управления изолированно и управлять ими путем модульного тестирования.

Теперь, я думал, что у меня есть решение, просто хочу знать, что вы, ребята, думаете об этом.

При нажатии кнопки Control A я помещаю «сообщение» в Сессию, то есть Session ["MESSAGES"] = "ControlA_Click".

В Page1, в Page_LoadComplete (), я помещаю вызов ProcessMessages, который выглядит следующим образом:

            List<Message> messages = SessionMessages.GetMessageList(Page);
        foreach(Message m in messages)
        {
            //Get Controls
            ControlA controlA = FindControl("controlA") as ControlA;
            controlA .ProcessMessage(m);

            ControlB controlB = FindControl("controlB") as ControlB;
            controlB.ProcessMessage(m);
      }

в методе ControlMessage () ControlB мы можем реагировать на сообщения, которые интересуют ControlB, следующим образом:

    if (m.MessageName == SessionMessages.C_MESSAGE_SEARCH)
{
    this.Visible = true;
}

Мне кажется, это работает. Это позволяет нам разрабатывать эти элементы управления полностью отдельно друг от друга, в то же время допуская межконтрольную связь на абстрактном уровне.

Единственное, о чем я могу подумать, это может привести к краху - это возможно жизненный цикл ASP.NET в отношении страниц и пользовательских элементов управления. Хотя я понимаю, что ВСЕ события должны были быть обработаны в элементах управления до вызова Page_LoadComplete () на странице-владельце.

Мысли

Answer 1

1. Элемент управления A должен вызвать событие
2. Страница, содержащая элементы управления, подписывается на событие и затем вызывает соответствующий метод в другом элементе управления
3. Элемент управления B должен обработать сообщение ()

Answer 2

Как намекает Бриджи, это именно то, что представляет собой Model-View Presenter. Вот статья о MVP в .NET, если вы хотите свернуть свою собственную.

В идеале вы хотите взглянуть на инфраструктуру MVC как на пример того, что вы можете сделать, когда все отделяете.

Обычно я делаю, чтобы событие нажатия кнопки вызывало событие, специфичное для домена, что-то вроде:

private void ControlA_OnClick(..)
{
  if(LoginRequested != null)
    LoginRequested(this, loginObj);
}

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

Answer 3

интересное злоупотребление сессией ...

вместо этого вы также можете разместить очередь сообщений на странице хостинга

Я бы порекомендовал вместо этого сделать так, чтобы страница хоста сделала что-то с элементом управления в ответ на сообщение, вместо того, чтобы сделать элемент управления «умным» - на самом деле не нужно, чтобы кнопка была «умной»

Answer 4

То, что у вас есть, в значительной степени EventBroker . Я не думаю, что сессия - подходящее место для этого, поскольку нет необходимости жить через запросы. HttpContext может работать, но если бы я не хотел, чтобы шина сообщений была разделена между IHttpModules и IHttpHandlers, я, вероятно, просто использовал бы базовый класс Page, для которого пользовательские элементы управления могут привести свой экземпляр страницы к:

interface IEventBroker {
 void Send(Message m);
}

class ControlA {
  void MyButton_Click(object sender, EventArgs e) {
     var eb = this.Page as IEventBroker;
     if (eb != null) eb.Send(new Message());
  }
}

или дать элементам управления ссылку на EventBroker - в этом случае я бы, вероятно, сделал сам EventBroker элементом управления и дал бы идентификатор каждому элементу управления, чтобы они могли использовать Page.FindControl.

Answer 5

Не для этого ли привязка данных? Элемент управления A реагирует на событие, которое обновляет модель, а затем вызывает привязку данных к ее зависимостям.

Если вы хотите создать систему обмена сообщениями, разработайте ее для издателя, и подписчику не нужно знать друг о друге, только само сообщение. Создайте интерфейс примерно так:

public interface IHandle<T> where T:IMessage
{
     void Process(T message)
}

Вам понадобится метод определения того, какие элементы управления реализуют его, и построения карты обработчиков messagetype->, посмотрите, как основные структуры DI обрабатывают внедрение свойств в элементы управления ASP .NET, чтобы увидеть, как этого можно добиться. Затем вы можете использовать один метод SendMessage, который отвечает за отправку сообщения всем элементам управления, которые могут обработать это сообщение. Чаще встречается такая модель в пользовательском интерфейсе форм.

Answer 6

Есть некоторые проблемы с этим подходом, такие как:
- «События» не проверяются при компиляции (вы можете легко напечатать имя события и узнать об этом во время выполнения или в худшем случае)
- Заполнение сеанса коммуникацией
- Вы должны поставить контрольные имена как строки - Если существует более одного элемента управления, который подписан на это событие, может стать трудно контролировать
- Когда параметры должны быть переданы между элементами управления, решение станет более сложным для управления

Лучшим подходом является использование встроенного механизма событий путем объявления событий на элементах управления:

public event EventHandler SpecialClick;

Каждый элемент управления, который должен что-то делать, будет подписываться на это событие

controlA.SpecialClick += new EventHandler(controlA_SpecialClick)

используя обычные события dot.net.

Answer 7

Ознакомьтесь с проектом Managed Extensibility Framework Contrib. У них есть только пример сайта, который вам нужен.