Потеря контроля над уровнем сложности проекта страшный сон любого разработчика, но как правило такие сны становятся явью в условиях глухоты и полного игнорирования простых принципов архитектурного дизайна, таких как разделение ответственности (Separation of Concerns, SoC) и слабая связанность (Loose coupling).
Проектирование и разработка в монолитном стиле приводит к приложению, которое очень трудно, дорого и неэффективно поддерживать. Слово "монолитное", указывает на приложение, в котором компоненты тесно связаны, и между ними нет четкого разделения. Приложения, спроектированные таким способом обладают качественной характеристикой «Трудно»: трудно добавлять новые функции, трудно заменять существующие, трудно исправлять ошибки, не затрагивая другие части системы, трудно работать параллельно и пр.
Сегодня существует немало практик построения хорошего дизайна различных архетипов приложений, которые рекомендуют, при построении уровня представления (Presentation Layer) применять ряд шаблонов, разделяющих: взаимодействие пользователя с UI, представление (View), бизнес-логику и данные приложения, с которыми работает пользователь. В настоящее время наиболее популярными являются MVC, MVP, MVVM и MVP-VM.
Хочу изложить свою практику применения шаблона MVP-VM на примере демо-решения Windows Form приложения, интерфейса управления заказами.
Model (Domain Models) - Модель предметной области, сердцевина всего приложения, описывает все бизнес-сущности, инварианты, их связи и функциональность.
Графически для демо-решения схема классов модели выглядит следующим:
Presenter - презентер определяет поведение и структуру приложения, не зависит от конкретной реализации пользовательского интерфейса. Презентер главным образом обеспечивает реализацию вариантов использования приложения, и координирует взаимодействие пользователя с бизнес-логикой.
В концепции MVP-VM презентер получает/отправляет объекты модели через фасад уровня бизнеc-логики, откуда (физически) пришли данные и что влияло на их объем ему неизвестно.
Инициализация презентера
При инициализации презентер запрашивает данные у объектов бизнес-служб, создает и наполняет ViewModel, настраивает View на отображение данных ViewModel.
Реализация варианта использования (Use case)
В простейшем случае обеспечение презентером варианта использования приложения осуществляется за счет кооперации объектов бизнес-служб, ViewModel и View:
• Запрос ответственных бизнес-служб
• Операции необходимые для реализации варианта использования
• Обновление ViewModel
• Команда View на обновление представления
Управление жизненным циклом View
В демо-решении основными объектами приложения являются презентеры, они управляют началом и завершением жизненного цикла View. Таким образом на единицу жизненного цикла презентера может быть несколько жизненных циклов View (череда открытий и закрытий окон).
Взаимодействие с дочерними презентерами
Для решения различных задач может потребоваться каскадирование презентеров и интеграция их функциональности. Родительский презентер может управлять жизненным циклом дочерних презентеров, взаимодействовать по средствам синхронных сообщений, событий или комбинированным способом.
При реализации варианта использования "Создание" и "Редактирование заказа" происходит синхронная передача управления дочернему презентеру, а для обратной связи используются события.
ViewModel - Определяет состояние представления, отвечает за организацию поступающих с бизнес-слоя данных в формат, пригодный для потребления компонентами UI. Например, ViewModel может агрегировать данные из многих источников и преобразовывать их для большего удобства отображения.
View - Конкретная реализация пользовательского интерфейса приложения.
Содержит визуальные элементы приложения, используемые для отображения данных пользователю и приема пользовательского ввода.
View в демо-решении построено по схеме Passive View, реализует интерфейс IOrderListView, доступный для управления представлением презентеру, обязательно содержит метод связывания данных BingData, в котором происходит настройка представления на отображение данных, а также связка с командами.
Business Logic Layer & Data Access Layer - Поскольку описание уровня бизнес - логики и доступа к данным выходит за границы данного поста, то здесь я остановлюсь.
View в демо-решении построено по схеме Passive View, реализует интерфейс IOrderListView, доступный для управления представлением презентеру, обязательно содержит метод связывания данных BingData, в котором происходит настройка представления на отображение данных, а также связка с командами.
Business Logic Layer & Data Access Layer - Поскольку описание уровня бизнес - логики и доступа к данным выходит за границы данного поста, то здесь я остановлюсь.
Исходный код демо-решения можно скачать здесь.
Используемые источники:
Проектировочный шаблон Model-View-Presenter-ViewModel для WPF
MVP-VM with Data Binding and BackgroundWorker in Windows Forms
Baldur's Gate Party Gold Editor - WPF, Windows Forms MVP-VM sample
MVVM for .NET Winforms – MVP-VM (Model View Presenter - View Model) Introduction
Паттерн MVP и Unity
Комментариев нет:
Отправить комментарий