Применение шаблона MVP в ASP.NET Webforms

В предыдущих постах знакомство с шаблоном MVP-VM, проводилось на наиболее подходящей для этого технологии Windows forms. Я неслучайно стал использовать эту технологию в качестве демонстрационной площадки, т.к. самые вопиющие нарушения принципа разделения ответственностей (Separation of Concerns) я наблюдал в проектах, использующих в качестве UI, Windows forms и ASP.NET Web forms. Дизайн таких проектов представляет кашу кода из доменной, инфраструктурной, презентационной логики в code behind’е форм, aka Smart UI. И все бы ничего до поры до времени, пока в результате экспоненциального роста сложности не начинают расти бюджеты ресурсов (деньги, люди) на поддержку проекта в ущерб развитию.

Описанные проблемы являются следствием пренебрежительного отношения к законам разработки программного обеспечения. В условиях постоянно расширяющегося проекта должны быть четко заданы параметры качества, в частности дизайна: концептуальная целостность, удобство и простота обслуживания, возможность повторного использования и пр., которые определят перечень законов разработки необходимых для удержания заданных границ качества. Но зачастую параметры качества дизайна никак формализованы, по принципу «ну это и так всем понятно!». А поскольку нет критериев качества, то нет и законов их соблюдения, нет проработки дизайна. И, первый закон, которого нет  - принцип единственной обязанности SRP (Single Responsibility Principle),  базовой целью которого является борьба со сложностью.

Следуя цели упрощения, для организации уровня представления, необходимо применять структурно-проектировочные шаблоны, такие как MVC и MVP, в которых ответственность за обработку задач UI разбивается на три роли: модель, представление, контроллер/презентер.

В данном посте я хочу обобщить описанные ранее практики разграничения ответственностей уровня представления на простом примере - фронта’ web приложения по схеме шаблона MVP.

Построение контекстно-зависимого интерфейса. Part II

В предыдущем примере построения контекстно-зависимого интерфейса, есть существенный минус - прямая зависимость между объектом, инициирующим операцию, и непосредственным исполнителем. В результате потери гибкости, мы не можем независимо изменить взаимодействие между инициатором и исполнителем операции. 

Плодить прямые зависимости между множествами объектов - гарантировать себе и коллегам, в будущем, головную боль, особенно в условиях постоянно развивающегося проекта. Поэтому, если вы не хотите, чтобы у вас отняли клавиатуру, нужно на ранней стадии проекта сказать прямым зависимостям решительное нет и обратиться к классике Design Patterns с существующими практиками. 

Для решения данной задачи давно используется шаблон Command, который отделяет объект инициирующий операцию, от объекта, который знает как её выполнить. Это позволяет добиться высокой гибкости при проектировании пользовательского интерфейса. Пункт меню и кнопка могут быть одновременно ассоциированы с методом презентера, для этого достаточно привязать оба компонента UI к одному и тому же экземпляру Command.

Далее необходимо будет развязать взаимодействие между компонентом UI и объектом Command, для этих целей подойдет шаблон-посредник (Mediator). Посредник знает о компоненте UI и о команде, управляет взаимодействиями между ними, таким как: активация/деактивация компонента UI, вызов метода Execute. 

Ну и чтобы совсем получилось вкусно, хочу чтобы решение работало на платформах WPF и Winforms, иначе для чего было городить весь огород с Separated Presenter. Поскольку WPF поддерживает работу с командами (в виде привязки объекта ICommand), а Windows Forms нет, то далее речь пойдет о практике взаимодействия команд и компонентов UI платформы Windows Forms

Построение контекстно-зависимого интерфейса. Part I.

Основными предпосылками построения контекстно-зависимого интерфейса является задача оградить конечного пользователя от действий которые им не могут быть выполнены в определенной фазе работы с программой. Типичным примером является меню управления файлами в проводнике Windows, предоставляющему пользователю операции: копировать, вырезать, вставить. Операция «вставить» доступна при наличии в буфере обмена ссылок на копируемые или вырезанные файлы, или если таких ссылок нет, то операция будет заблокирована или полностью скрыта. Таким образом интерфейс побуждает пользователя выполнить определенную последовательность действий для получения доступной операции. В частности, предварительно скопировать требуемые для переноса или копирования файлы в буфер обмена.

Игнорирование управлением доступными операциями, приводит конечного пользователя в замешательство, неясно какие операции доступны, а какие нет, непонятно в каком режиме работает приложение и пр. Представьте себе, вам пришла задача визирования документа, с перечнем доступных операций согласовать, утвердить, ознакомиться, исполнить. Вам с ходу не ясно что от вас требуются, и вы начинаете пробираться на ощупь. Вы пробуете выполнить поочередно операции выстроив тем самым общую картину, посредствам перечитывания сообщений о недопустимости действий: «нет прав», «не для Вашей роли», «не для этого этапа» и пр. И хорошо если вообще существует обратная связь в виде информационных сообщений, то её и вовсе не бывает, или программа попытается выполнить недопустимую операцию и вернет пользователю «Object reference not set to an instance of an object».

Описанные проблемы возникают, когда не закладываются на эргономику и разработку удобного, дружелюбного интерфейса, но мой пост не о юзабилити, я рассмотрю основные техники построения контекстно-зависимого интерфейса.

UserControls в MVP-VM и повторное использование презентера

Зачастую при проектировании UI форм интерфейса возникает задача скомпоновать стандартные элементы управления в некоторый более высокоуровневый объект с индивидуальным поведением в целях инкапсуляции и/или повторного применения. 

В данном посте я опишу возможность повторного использования презентера для управления различными элементами UI.

Сама идея повторного использования презентера противоречит догме Билла Кратохвила о том, что «презентер не предназначен для повторного использования», я не собираюсь опровергать авторитетного эксперта (без иронии), а изложу мое видение.

Итак, еще раз, кто такой презентер:

Presenter – (англ.) представитель, а в жаргоне сотрудников TV эфира (TV news presenter)  - ведущий (программы). Последнее, по моему мнению, как нельзя лучше отображает его назначение. Я пошёл дальше и провел аналогию презентера с продюсером эстрадной звезды, детально расписав цели, роли, ответственности, но нашел в себе силы вовремя остановиться J

И все же, в концепции шаблона MVP-VM, presenter является представителем не только интерфейса пользователя, но и отвечает за то, каким функционалом этот интерфейс будет обладать. Функционал представления здесь ключевая фраза, именно эту характеристику я и буду повторно использовать. 

Практика применения шаблона MVP-VM (Winforms)

Потеря контроля над уровнем сложности проекта страшный сон любого разработчика, но как правило такие сны становятся явью в условиях глухоты и полного игнорирования простых принципов архитектурного дизайна, таких как разделение ответственности (Separation of Concerns, SoC) и слабая связанность (Loose coupling).

Проектирование и разработка в монолитном стиле приводит к приложению, которое очень трудно, дорого и неэффективно поддерживать. Слово "монолитное", указывает на приложение, в котором компоненты тесно связаны, и между ними нет четкого разделения. Приложения, спроектированные таким способом обладают качественной характеристикой «Трудно»: трудно добавлять новые функции, трудно заменять существующие, трудно исправлять ошибки, не затрагивая другие части системы, трудно работать параллельно и пр.

Сегодня существует немало практик построения хорошего дизайна различных архетипов приложений, которые рекомендуют, при построении уровня представления  (Presentation Layer)  применять ряд шаблонов, разделяющих: взаимодействие пользователя с UI, представление (View), бизнес-логику и данные приложения, с которыми работает пользователь. В настоящее время наиболее популярными являются MVC, MVP, MVVM и MVP-VM.

Хочу изложить свою практику применения шаблона MVP-VM на примере демо-решения  Windows Form приложения, интерфейса управления заказами.