Разработка графического пользовательского интерфейса в соответствии с паттерном Model-View-Viewmodel на платформе Windows Presentation Foundation. Осн

УДК 004.514(07) H191

Рецензенты:

Г.А. Воробьев, канд. техн. наук; кафедра электроники, телекоммуникаций и компьютерных технологий

Липецкого государственного педагогического университета.

Назаркин О. А.

H191 Разработка графического пользовательского интерфейса в соответствии с пат-

терном Model-View-Viewmodel на платформе Windows Presentation Foundation.

Основные средства WPF [Текст]: учеб. пособие по дисциплине «Проектирование человеко-машинного интерфейса» / О. А. Назаркин. - Липецк : Изд-во Липецкого государственного технического университета, 2014. - 61 с.

ISBN 978-5-88247-679-2

Пособие предназначено для студентов направлений «Информатика и вычислительная техника», «Программная инженерия», «Математическое обеспечение и администрирование информационных систем», а также родственных направлений и специальностей. Для изучения пособия требуется знание C#, XML и общее представление о программной платформе .NET.

В пособии анализируются принципы, положенные в основу WPF, а также MVVM – современный паттерн реализации систем с GUI. Даны простые примеры и рекомендации по проектированию и реализации программных модулей. Пособие ориентировано на построение у студентов прочного фундамента из элементарных концепций.

Ил. 3. Библиогр.: 3 назв.

УДК 004.514(07) H191

ISBN 978-5-88247-679-2

© ФГБОУ ВПО «Липецкий государственный технический университет», 2014

Введение. О двух аспектах сложности GUI

Разработка графического пользовательского интерфейса (Graphical User Interface, GUI) не без оснований считается трудоемким процессом. Сложность GUI объективно определяется большим количеством информации, которую развитый пользовательский интерфейс должен пропускать через свои многочисленные и разнородные элементы (окна, панели, кнопки, надписи, графические фрагменты и многие другие) в рамках человеко-машинного взаимодействия. Нередко прикладные задачи требуют сотен диалоговых элементов. Окно текстового процессора, в котором набираются эти строки, служит наглядным подтверждением. (Причем возможность скрыть редко используемые инструменты редактирования и оставить на виду только самые необходимые не упрощает, а, напротив, еще более усложняет организацию интерфейса!)

Но существует и другой аспект сложности GUI, не связанный непосредственно с предметной областью и решаемыми задачами. Иными словами, эта сложность будет присутствовать и в относительно простых по форме интерфейсах. Дело в том, что для программной реализации GUI требуется особый язык. Универсальные языки программирования не позволяют лаконично описывать структуру типичного GUI и алгоритмы его функционирования. Кроме того, доступ приложений к средствам графического вывода и получение информации от устройств ввода контролируются операционной системой. Следовательно, она должна предоставлять соответствующие системные библиотеки, пользуясь которыми приложения могут безопасно и согласованно осуществлять ввод и вывод информации в диалоговом режиме. Таким образом, требуется определенная совокупность системного программного и лингвистического обеспечения, которую для краткости часто называют

платформой GUI.

4

Современные интегрированные системы программирования предоставляют разработчикам мощные и гибкие платформы GUI. Как следует ожидать, они достаточно сложны, их освоение может потребовать длительного времени, а для правильного и эффективного применения этих средств необходимо понимать принципы и модели, положенные в их основу.

В настоящем пособии рассматривается платформа WPF – Windows Presentation Foundation, точнее, лишь очень узкий участок спектра ее возможностей. Задача пособия — показать, как с использованием базовых элементов WPF можно разрабатывать лаконичные, надежные, согласованные графические интерфейсы. Предлагается описание идей и концепций, составляющих основу программных паттернов MVC и MVVM, а также иллюстрируется применение основных инфраструктурных составляющих WPF: зависимых свойств, связываемых данных, маршрутизируемых событий, команд.

5

Паттерн MVC как основа разработки GUI

Одним из исторически первых паттернов разработки GUI является паттерн MVC (Model-View-Controller). Его задача – изолировать модель предметной области от ее представления в пользовательском интерфейсе. Здесь под изоляцией понимается «неосведомленность» модели о том, что она отображается пользователю. При этом модель должна принимать команды на выполнение каких-либо действий, предусмотренных предметной областью, возвращать по запросу значения своих внутренних атрибутов, а также сообщать об изменениях внутреннего состояния, чтобы можно было синхронно обновлять отображение (рис. 1).

Рис. 1. Принцип изоляции модели от представления

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

6

При анализе этой схемы возникает вопрос: кому и каким образом модель сообщает об изменениях своего состояния? Ответ на первую часть вопроса («Кому?») может быть неопределенным: никому в отдельности, а просто во внешнюю среду; кто слушает, тот услышит. А вот для ответа на вторую часть вопроса («Каким образом?») требуется поддержка со стороны платформы.

Представим себе, что в модели в ходе обработки данных изменилось значение некоторой внутренней переменной состояния. Модель должна сообщить об этом, не имея информации о потенциальных приемниках сообщения. Распространенный способ решения такой задачи – callback-механизм («обратный вызов»), т.е. вызов функции, адрес которой заносится в модель из внешней среды. Callback-функция даже может не получать аргументов, а ее вызов просто сигнализирует, что внутреннее состояние модели изменилось и желающие узнать подробности этих изменений могут воспользоваться стандартным опросом состояния модели через ее программный интерфейс.

Алгоритм callback-функции по возможности должен быть быстрым, чтобы не влиять на ход работы модели. Кроме того, следует избегать рекурсии, при которой внутри callback-функции вызываются какиелибо действия над моделью, вновь приводящие к изменению ее состояния и необходимости нового callback-вызова, и так далее. (Рекурсия в данном случае не является принципиальным запретом, но ее последствия должны контролироваться.) Модель не интересуют детали callback-реализации, она предполагает только то, что эта функция по смыслу соответствует возбуждению события «Состояние модели изменено».

Пользовательский интерфейс включает две составляющие: ввод и вывод. Решаемые в их рамках задачи существенно связаны друг с другом. Например, при манипуляциях, осуществляемых пользователем с

7

помощью мыши над экранным представлением какого-либо объекта, требуется непрерывно отслеживать координаты курсора мыши (ввод) и синхронно с этим отображать объект в новом положении (вывод).

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

(рис. 2).

Рис. 2. Разделение блоков ввода и вывода

Схема на рис. 2 представляет классический паттерн MVC. Блок графического рендеринга обычно обозначается View, обработка пользовательского ввода – Controller. Смысловая нагрузка термина controller (блок управления) указывает на то, что этот компонент является ответственным за принятие решений по управлению моделью (Model) на основании данных и команд, получаемых от пользователя через устройства ввода. Компонент View (представление) обычно не имеет ни возможности, ни необходимости воздействовать на модель. Его задача – «вытягивать» из модели и проецировать на экран текущие значения отображаемых атрибутов, своевременно реагируя на сигналы об обновлении состояния.

8

отображения формат. Все это требует описания на алгоритмическом языке.

С другой стороны, чтобы написать процедуры реакции на события пользовательского ввода, программист должен знать, какие конкретно элементы GUI использовал дизайнер на форме, какова общая схема ви-

зуальной компоновки, определяющая действия при изменении разме-

ров и других свойств формы, каковы условия и ограничения видимости и доступности элементов и многое другое.

Следовательно, дизайнер в лучшем случае сможет выполнить ста-

тичные эскизы экранной формы в разных режимах ее работы при раз-

ных условиях, а программист должен создать все алгоритмические про-

цедуры обслуживания. Если дизайнер решит изменить набор графиче-

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

нужденная и необоснованная зависимость программистов от дизайне-

ров, что в проекте по разработке программного обеспечения может рас-

цениваться как организационный дисбаланс.

Для восстановления баланса усилий и инициатив разных участни-

ков проекта желательно, во-первых, устранить необходимость примене-

ния императивных алгоритмических сценариев в блоке графического отображения, во-вторых, сделать реакцию на события пользовательско-

го ввода независимой от конкретных типов и расположения элементов

GUI.

Эти задачи решает паттерн MVVM (Model-View-ViewModel), в кото-

ром компонент ViewModel – модель представления – является адапте-

ром модели для взаимодействия с графическим интерфейсом (рис. 3).

10