MVP веб-форм Пассивное Представление - обработка событий
Представление ничего не должно иметь событие, конкретное в его интерфейсе и назвать простые методы предъявителя, чтобы обработать события и не иметь какой-либо официальный EventHandlers? Например,
// ASPX
protected void OnSaveButtonClicked(object sender, EventArgs e)
{
_Presenter.OnSave();
}
Или если представлению определили событие EventHandlers в его интерфейсе и соединяет их явно для управления событиями на странице
// View
public interface IView
{
...
event EventHandler Saved;
...
}
// ASPX Page implementing the view
protected override void OnInit(EventArgs e)
{
base.OnInit(e);
SaveButton.Click += delegate { Saved(this, e); };
}
// Presenter
internal Presenter(IView view,IRepository repository)
{
_view = view;
_repository = repository;
view.Saved += Save;
}
Второе походит на большую инфраструктуру кода для добавления на всем протяжении.
Мое намерение состоит в том, чтобы понять преимущества каждого стиля и не только, общий ответ которого можно использовать. Моими главными целями является ясность, и высоко оцените тестируемость. Тестируемость в целом важна, но я не пожертвовал бы простотой дизайна и ясностью, чтобы смочь добавить другой тип теста, который не ведет, чтобы слишком много получить по тестовым сценариям, уже возможным с более простым дизайном. Если проектное решение делает от большей тестируемости, включайте пример (псевдо код прекрасен) типа теста, который это может теперь предложить так, я могу принять свое решение, если я оцениваю тот тип дополнительного теста достаточно.Спасибо!
Обновление: для моего вопроса нужно дальнейшее разъяснение?
3 ответа
В интерфейсе вашего представления вы должны иметь ссылку на кнопку сохранения, и тогда все будет сделано в презентаторе. Это освобождает ваше представление от кода и позволяет легко тестировать вашего preseneter.
// View interface
public interface IView
{
Button SaveButton;
}
// View code behind
public Button SaveButton
{
get { return btnSave; }
}
// Presenter
internal Presenter(IView view,IRepository repository)
{
_view = view;
_repository = repository;
view.SaveButton.Click += new EventHandler(Saved);;
}
void Saved(object sender, EventArgs e)
{
// do save
}
'
Мы только что реализовали MVP, используя веб-формы, и выбрали более простой вариант, когда представление вызывает методы ведущего напрямую для событий кнопок и т.д.
Наше обоснование заключается в том, что мы не можем напрямую тестировать представление (мы используем waitin для тестирования этого слоя), поэтому главная цель здесь - иметь тестируемый ведущий, который отделен как можно дальше от представления/модели.
По моему опыту, вы никогда не добьетесь абсолютно чистого MVP в WebForms в силу природы этого зверя (им бы очень хотелось, чтобы вы просто использовали этот код за файлом...), так что я бы не стал зацикливаться на этом.
В конце концов, вам нужно оценить причины разделения логики представления и логики презентации и определить, поможет/помешает ли вам тот или иной метод в дальнейшем.....
Мне не нравится иметь явную ссылку на Button (или любой другой элемент управления) в интерфейсе. Это означает, что мы тесно связаны с реализацией контроля (ов).
Элементы управления могут быть реализованы очень по-разному в разных типах проектов (например, Winforms и ASP).
Это означает, что интерфейс потенциально должен быть изменен для разных представлений, что именно то, что мы не хотим. Весь смысл MVP заключается в том, что Presenter может полагаться на стабильный интерфейс, который позволяет отделить пользовательский интерфейс от модели, легкую подмену конкретных представлений и тестируемость.
Лучше придерживаться свойств и методов интерфейса, которые не зависят от каких-либо конкретных элементов управления, и оставить детали реализации конкретным представлениям.