Предыдущая часть Здесь .
Оригинальная статья Здесь .
Модель-представление-презентатор (MVP) Архитектура MVP впервые появилась в IBM и стала более выраженной с появлением системы Taligent в 1990-х годах.
Достаточно подробно описано в работе Потеля ( Потель ).
Идею подхватили разработчики Дельфин Smalltalk .
Как мы увидим позже, эти две работы не говорят об одном и том же, но идея, лежащая в их основе, стала очень популярной.
Мы будем ссылаться на эти два источника при описании архитектуры.
Прежде чем приступить к описанию MVP, мне кажется полезным подумать о существенных различиях между двумя столпами разработки пользовательского интерфейса.
С одной стороны, это Forms and Elements, архитектура, которая является основным направлением дизайна пользовательского интерфейса.
С другой стороны — MVC и его производные.
Модель форм и элементов предоставляет разработчику простой для понимания дизайн и позволяет легко отделить повторно используемые элементы управления от бизнес-кода приложения.
Ему не хватает того, что есть в изобилии у MVC — разделенного представления ( Отдельная презентация ) и контекст программирования, определяемый использованием модели предметной области ( Модель предметной области ).
Я рассматриваю MVP как комбинацию этих двух моделей, как попытку взять от них лучшее.
По мнению Потеля, под представлением в MVP следует понимать структуру элементов управления формой в модели «Формы и элементы», и любое разделение управления на контроллер/представление должно быть удалено.
Представление не должно содержать никакого поведения, определяющего, как элемент взаимодействует с пользователем.
Это взаимодействие осуществляется в отдельном объекте представления (презентаторе).
Базовые обработчики событий управления остаются в представлении, но их цель — передать управление презентатору.
Ведущий должен определить, как реагировать на событие.
Потель определяет это взаимодействие как действия над моделью, которые происходят через систему команд и выборов.
Кстати, можете взять на заметку такой подход — упаковка всех редакций модели в команду.
Это позволит вам легко ввести поведение отмены/повтора.
Обратное обновление из модели в вид происходит через ту же синхронизацию через апдейтер ( Синхронизация наблюдателей ), который используется в MVC. Аналогичное описание дано в работе Дельфин .
Также требуется наличие объекта-презентатора.
Однако Dolphin не определяет систему взаимодействия ведущего и модели.
Кроме того, здесь явно указано, что объект-представитель должен иметь прямой доступ к представлению.
Потель ничего не говорит о том, должен ли презентер иметь доступ к представлению или нет, но для Dolphin такое поведение очень важно именно из-за проблемы в Модели Приложения с отклонением цвета, которую я описал в предыдущем разделе.
Как вы помните, она решалась таким топорным, с моей точки зрения, способом.
Еще одним ключом к пониманию MVP является понимание того, как докладчик управляет элементами презентации.
С одной стороны, Потель утверждает, что вся логика представления должна оставаться в представлении и ведущий не должен определять рендеринг модели.
Господа Бауэр и МакГлашан предложить свое решение, которое я называю Контролер-контролер .
В этом решении почти вся логика представления также определена в представлении, но презентатор имеет возможность влиять на эту логику в сложных сценариях.
Те.
некоторая часть логики представления может быть помещена в презентатор.
Кроме того, вы можете полностью передать всю логику представления ведущему и получить то, что я называю Пассивный просмотр .
Пассивный просмотр изначально не был частью модели MVP. Эта модель появилась позже, когда люди научились решать задачи тестирования.
Об этой модели я расскажу позже, а пока просто скажу, что это разновидность MVP. Прежде чем определить отличие MVP от всего остального, что я описал выше, хотелось бы сказать несколько слов об упомянутых мной работах.
Они определяют разницу между MVP и MVC, но не так, как я это вижу.
Потель утверждает, что контроллеры в MVC являются общими координаторами, с чем я не согласен.
Dolphin много говорит о проблемах MVC, и под MVC подразумевают модель приложения VisualWorks, а не тот классический MVC, о котором я говорил.
Я их в этом не виню — информацию о классическом MVC в наши дни получить не так-то просто.
Теперь самое время поговорить об отличиях MVP от предыдущих архитектур (какими я их вижу):
- Формы и элементы: MVP имеет модель и ведущий манипулирует этой моделью с помощью синхронизации через браузер ( Синхронизация наблюдателей ) при обновлении представления.
И хотя прямой доступ к элементам управления ведущего разрешен, пользоваться этим доступом — дурной тон.
- MVC: Для управления моделью модель MVP использует Контролер-контролер .
?Элементы управления передают пользовательский ввод Контролер-контролер .
Элементы управления не разделены на представления и контроллеры.
Presenter можно рассматривать как контроллер, но без первоначальной обработки ввода пользователя.
Важно то, что презентер — это объект уровня формы, а не объект уровня управления — на мой взгляд, это еще большая разница.
- Модель приложения: представления передают события презентатору так же, как они передают их модели приложения.
Однако представление в MVP может обновляться непосредственно из модели предметной области, поскольку презентатор не является моделью представления ( Модель презентации ).
Кроме того, докладчик может иметь прямой доступ к элементам управления, что невозможно при синхронизации с браузером ( Синхронизация наблюдателей ).
Presenter — это просто более свободная форма контроллера.
В результате многие архитектуры будут следовать по пути MVP, но будут использовать термин «контроллер» для обозначения презентатора.
Вообще говоря, вам нужно использовать контроллер, когда вы имеете дело с проблемой взаимодействия с пользовательским вводом на уровне элемента управления.
Рис.
12. Диаграмма последовательности обновления текущего значения в модели MVP. Давайте посмотрим, как работает обновление текущего значения на примере мороженого (рис.
12 ).
Начало диаграммы очень похоже на то, что было в «формах и элементах» — пользователь вводит значение, текстовое поле отправляет событие «текст изменен».
Presenter прослушивает это событие и перехватывает его, после чего принимает новое значение из представления.
Затем он обновляет объект домена, который, в свою очередь, отображается в текстовом поле отклонения.
Текстовое поле отклонения обновляет свое значение расчетным значением, а затем ему присваивается цвет. Цвет назначает ведущий.
Он считывает категорию отклонения измерения и обновляет цвет текстового поля (через прямую ссылку на элемент управления).
Подведем итог модели MVP:
- Взаимодействия пользователя (события) передаются элементами управления Контролер-контролер , где происходит дальнейшая обработка.
- Ведущий координирует изменения в модели предметной области.
- Реализация обновления представления разными вариациями MVP осуществляется по-разному.
Количество способов начинается с обновления через браузер ( Синхронизация наблюдателей ) и заканчивается ручным обновлением каждого элемента управления презентатором.
Теги: #программирование #архитектура программного обеспечения #перевод #программирование
-
Издание Vc.ru Ищет Авторов-Фрилансеров.
19 Oct, 24 -
Собственная Область Безопасности В Glassfish
19 Oct, 24 -
Игры И Люди
19 Oct, 24 -
Windows Mobile 6.5 — Виджеты Windows Mobile
19 Oct, 24 -
Выход/Вход В Гараж Закрыт, Что Делать?
19 Oct, 24
