Здравствуйте, Иван Бодягин, Вы писали:
ИБ>Статья:
ИБ>Model-View-Controller в .NetАвтор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.
В статье для оповещения Presenter-a об изменениях во View используется событие:
public interface IView
{
/// <summary>
/// Событие ввода значения по цельсию
/// </summary>
event EventHandler<EventArgs> SetCelsius;
}
и в реализации View:
/// <summary>
/// Обработка событий тоже примитивна, они просто пробрасываются
/// в соответствующие события Presenter-а
/// </summary>
private void _celsiusButton_Click(object sender, EventArgs e)
{
if (SetCelsius != null)
SetCelsius(this, EventArgs.Empty);
}
Presenter подписывается на это событие и обрабатывает его должным образом.
У меня возник очень серьезный спор по поводу использования событий для обработки изменеий во View. Альтернатвным решением коллеги предлагают иметь во View ссылку на Presenter, а в Presenter-е объявить
public void SetCelsius();
а View изменить следующим способом:
private void _celsiusButton_Click(object sender, EventArgs e)
{
_presenter.SetCelsius();
}
Покопавшись в сети, я нашел несколько статей, объясняющих, почему прямые вызовы могут быть лучше, чем события (например,
здесь).
В кратце — легче читать и отлаживать код, легче юнит-тестирование.
В связи с этим вопрос — какие преимущества использования событий для вызова кода Presenter-а из View и когда какой подход выбирать?
