CC BY
60
ТЕХНИКА, ТЕХНОЛОГИЯ, УПРАВЛЕНИЕ
УДК 004.5; 004.05
СРАВНИТЕЛЬНЫЙ АНАЛИЗ ШАБЛОНОВ
ПРОЕКТИРОВАНИЯ ПРИЛОЖЕНИЙ С ПОЛЬЗОВАТЕЛЬСКИМ ИНТЕРФЕЙСОМ
С. С. Ликсин1, П. А. Лукошкин2, С. В. Шибанов3
^ 2'3Пензенский государственный университет, Пенза, Россия
1lss124@yandex.ru 2654pavel456@mail.ru 3serega@pnzgu.ru
Аннотация. Исследуются шаблоны (паттерны) проектирования приложений с пользовательским интерфейсом - Model-View-Controller, Model-View-Presenter, Model-View-ViewModel - с точки зрения практического применения в процессе разработки. Выполнен сравнительный анализ паттернов. Обосновывается выбор паттерна для разработки приложений с пользовательским интерфейсом.
Ключевые слова: паттерны, паттерны проектирования пользовательских интерфейсов, модель, представление, Model-View-Controller, Model-View-Presenter, Model-View-ViewModel
Для цитирования: Ликсин С. С., Лукошкин П. А., Шибанов С. В. Сравнительный анализ шаблонов проектирования приложений с пользовательским интерфейсом // Вестник Пензенского государственного университета. 2021. № 4. С. 79-85.
Все программисты в мире решают более-менее похожие задачи, и для решения этих задач уже выработаны популярные решения - паттерны. Паттерны - это устойчивые конструкции в программировании [1]. Паттерны помогают сэкономить время на организацию кода и сосредоточиться на решении задачи. Существуют паттерны, позволяющие грамотно реализовать отдельные решения в коде, например паттерн «перечисление», есть паттерны, которые позволяют настраивать общение различных модулей, например паттерн «инверсия контроля». Применение паттернов позволяет упростить реализацию проекта, обеспечить читаемость кода, позволит использовать отдельные компоненты повторно, а также увеличит эффективность совместной разработки. Самые используемые и общие паттерны объединяют в порождающие (фабрика, прототип, строитель, одиночка), структурные (адаптер, мост, компоновщик) и поведенческие (посредник, итератор, наблюдатель) [1].
При разработке приложения с использованием пользовательского интерфейса используются паттерны, описывающие, как эффективно разделить код приложения по папкам, что реализовывать в конкретных файлах, а также как настраивать связи между компонентами. Примером подобного паттерна является паттерн MVC (Model-View-Controller) и его аналоги MVP (Model-View-Presenter) и MVVM (Model-View-ViewModel) [2-5]. В дан-
© Ликсин С. С., Лукошкин П. А., Шибанов С. В., 2021
79
ной статье мы расскажем, в чем особенности данных паттернов, а также на каких платформах и для каких задач эти паттерны применяются. Все эти паттерны связаны с двумя общими сущностями - моделью (Model) и представлением (View).
Модель - это часть, содержащая в себе функциональную бизнес-логику приложения. Модель должна быть полностью независима от остальных частей продукта. Модельный слой ничего не должен знать об элементах дизайна, и каким образом он будет отображаться. Достигается результат, позволяющий менять представление данных, то как они отображаются, не трогая саму модель [2, 3].
Модель обладает следующими признаками:
- модель - это бизнес-логика приложения;
- модель обладает знаниями о себе самой и не знает о контроллерах и представлениях;
- для некоторых проектов модель - это просто слой данных (DAO, база данных, XML-файл);
- для других проектов модель - это менеджер базы данных, набор объектов или просто логика приложения.
Представление - отображение данных, полученных от модели. Однако представление не может напрямую влиять на модель. Можно говорить, что представление обладает доступом «только на чтение» к данным [2, 3].
Представление обладает следующими признаками:
- в представлении реализуется отображение данных, которые получаются от модели любым способом;
- в некоторых случаях представление может иметь код, который реализует некоторую бизнес-логику.
Впервые концепция MVC была описана в 1979 г. MVC состоит из трех компонент: View (представление), Model (модель) и Controller (контроллер). Контроллер содержит логику на изменение модели при определенных действиях пользователя [2, 3].
Основная идея этого паттерна в том, что контроллер и представление зависят от модели, однако модель независима. Это как раз и позволяет разрабатывать и тестировать модель, ничего не зная о представлениях и контроллерах. При этом один и тот же контроллер, благодаря подобному строению, можно использовать для разных представлений. Так, например, контроллер может зависеть от пользователя, который вошел в систему.
Пользователь видит представление, на нем производит какие-то действия, эти действия представление перенаправляет контроллеру и подписывается на изменение данной модели; контроллер, в свою очередь, производит определенные действия над моделью данных, представление получает последнее состояние модели и отображает ее пользователю.
MVC используется, когда связь между представлением и другими частями приложения невозможна. Поскольку проектная идея MVC заключается в том, чтобы начать с модели без учета сложности пользовательского интерфейса, проблема, вызванная этим, заключается в том, что модели трудно соответствовать сложным и частым изменениям стороны просмотра. По сравнению с этим MVP и MVVM более универсальны. Все они имеют независимый компонент (Presentor и ViewModel), соответствующий каждому View [4, 5]. Структура шаблона MVC представлена на рис. 1.
Model-View-Presenter состоит из трех компонент: Model (модель), View (представление) и Presenter. Представлению нет необходимости подписываться на изменения модели. Контроллер, переименованный в Presenter, дает знать представлению об изменениях [2-4].
Данный подход позволяет создавать абстракцию представления. Реализовать данный паттерн можно при помощи вынесения интерфейсов представления (IView). У каждого представления будут интерфейсы с определенными наборами методов и свойств, необходимых Presenter. Presenter, в свою очередь, инициализируется с данным интерфейсом, подписывается на события представления и по необходимости передает данные.
Рис. 1. Структура шаблона Model-View-Controller
MVP используют в ситуации, когда связывание данных невозможно либо требует слишком много дополнительного кода. Частым примером является технология Windows.Forms и реализация интерфейсов средствами движка Unity.
В MVP Presenter полностью разделяют модель и представление, а основная логика программы реализована в Presenter. Мы можем изменять представление, не влияя на модель. Модель можно использовать более эффективно, поскольку все взаимодействия происходят в одном месте - внутри Presenter. Мы можем использовать один Presenter для нескольких представлений без изменения логики Presenter. Эта возможность очень важна, потому что представление меняется чаще, чем модель. Если мы поместим логику в Presenter, то сможем протестировать логику без пользовательского интерфейса (модульный тест) [5]. Структура шаблона MVP представлена на рис. 2.
Рис. 2. Структура шаблона Model-View-Presenter
MVVM - это шаблон, который появился для обхода ограничений паттернов MVC и MVP, объединяющий некоторые из их сильных сторон. Эта модель впервые появилась в составе фреймворка Small Talk в 1980-х гг. и была позднее улучшена с учетом обновленной модели презентаций (MVP).
Шаблон MVVM имеет три основных компонента: Model (модель), View (представление), и ViewModel (представление-модель). В ViewModel содержится вся логика построения графического интерфейса и ссылка на модель, поэтому он выступает в качестве модели для представления [2-4].
Можно утверждать, что каждый слой этого паттерна не знает о существовании другого слоя. Пользовательский интерфейс абстрагируется в независимые представления,
а разработка, ориентированная на компоненты, преобразуется в разработку, ориентированную на представления. Каждое представление управляется независимой моделью представления (ViewModel) [5].
MVVM чаще всего используется, когда возможно связывание данных без необходимости ввода специальных интерфейсов представления. Частым примером является технология WPF. При использовании этого паттерна представление не реализует соответствующий интерфейс (IView). Представление должно иметь ссылку на источник данных (DataContex), которым в данном случае является View-модель. Элементы представления связаны (Bind) с соответствующими свойствами и событиями View-модели. В свою очередь, View-модель реализует специальный интерфейс, который используется для автоматического обновления элементов представления. Примером такого интерфейса в WPF может быть INotifyProperty Changed [6]. Структура шаблона MVVM представлена на рис. 3.
Рис. 3. Структура шаблона Model-View-ViewModel
Какой же паттерн стоит выбрать для вашего проекта? Ответ зависит от сложности проекта, загруженности пользовательского интерфейса и возможностей среды разработки.
В ходе исследования было решено реализовать приложение с использованием пользовательского интерфейса. Суть проекта в следующем: хранилище нефти состоит из нескольких резервуаров и предназначено для накопления, хранения и отгрузки нефтепродуктов. Каждый из резервуаров оборудован двумя насосами, один из которых осуществляет закачку нефти в резервуар, а второй - откачку нефти из резервуара. Каждый из насосов может находиться во включенном или выключенном состоянии (рис. 4, 5).
Рис. 4. Проект «Нефтехранилище»
OllStorage
tanks: List<Tank>
Включить нефтехранилищеО Выключить нефтехранилищеО Просмотреть информацию обо всех резервуарахО Полечить общее количество нефти в нефтехранилищеО
-F-
1
Tank
Насос подкачки нефти : Pump Насос откачки нефти : Pump Состояние: Boolean Максимальный уровень нефти : Double Минимальный уровень нефти : Double Уровень нефти : Double
Получить уровень нефтиО Остановить работ/ резервуараО Переключить один из насосовО Запустить работу резервуараО
2
Pump
Состояние насоса: Boolean Скорость перекачки нефти : Double
Включить насосО Выключить насосО
Рис. 5. Диаграмма классов модели
Для подобного приложения требуется реализовать интерфейс взаимодействия с выбранным резервуаром, а также реализовать интерфейс настройки резервуара. Для упрощения реализации проекта «Нефтехранилище» было решено использовать один из паттернов проектирования пользовательских интерфейсов. Было решено реализовать проект на языке C#, в среде разработки Visual Studio 2017, средствами платформы Unity.
Модель и представление, представленные выше, требуют дополнительный компонент, который будет связывать действия пользователя и реакцию на них логики программы [2]. Для этого требуется выбрать, какой из паттернов (а, следовательно, и какой из компонентов) стоит использовать для реализации данного проекта: MVC [3], MVP [4], MVVM [6]. Ключевые особенности рассматриваемых паттернов представлены в табл. 1.
Таблица 1
Особенности MVC, MVP, MVVM
Признаки сравнения Платформа Применение Плюсы Минусы
ModelViewController ASP.NET Интернет-сайты и веб-приложения Меньше кода. Непостоянный доступ к модели Усложненное модульное тестирование и инкапсуляция. Слабое разделение ответственности
ModelView-Presenter Windows. Form, Unity 3D Простые приложения с использованием сторонних библиотек Легко тестировать. Компоненты повторно используются. Общие модули Необходимо работать с интерфейсом представлений (IView). Лишний шаблонный код
ModelViewViewModel UPF, WPF Сложные приложения, работающие с множеством источников данных Прост в написании тестов. Части приложения не зависимы друг от друга Сложность в использовании одного View с несколькими ViewModel. Требуются дополнительные события
В случае проекта «Нефтехранилище» затраты времени и памяти, занимаемой приложением при реализации всех паттернов, почти не различаются. Интерфейс (рис. 6) достаточно простой, его сильное расширение не планируется. Внешних источников информации нет, поддерживается постоянный доступ к модели. В Unity также реализованы встроенные интерфейсы представления для самых используемых элементов интерфейса, таких как Button, TextBox, CheckBox, ListBox и т.д.
Резервуар №1 Настройки
Максимальное значение: 100
Включить закачку нефти Текущее значение: 0 Включить! откачку 1 нефти
Минимальное значение: 0
Рис. 6. Интерфейс приложения «Нефтехранилище»
В результате анализа для реализации проекта «Нефтехранилище» было решено использовать паттерн Model-View-Presenter, так как его реализация на платформе Unity сильно упрощает разработку. Сложность интерфейса нашего проекта не настолько высока, чтобы использовать паттерн MVVM, а связывание данных потребует дополнительного кода, с минимальным выигрышем по времени и качеству разработки. Использование MVC
возможно, однако преимущества платформы Unity позволяют реализовать паттерн MVP намного быстрее.
Поскольку Windows.Form и Unity не могут поддерживать двустороннюю привязку данных и интерфейс, а также мониторинг событий либо их использование без применения дополнительных библиотек вызывает затруднения и сильно осложняет код, MVP -лучший выбор в Windows.Form и Unity. Однако, если бы нам потребовалось реализовать сложный многоуровневый интерфейс для какого-либо приложения, то наш выбор пал бы на MVVM. В Unity 3D существуют различные библиотеки с реализацией связывания данных, однако почти все они платные. Реализация же связывания самостоятельно потребует значительного времени и усилий, что сильно замедлит разработку. Поэтому использование MVVM в Unity 3D имеет смысл, если для проекта необходимо реализовать сложный многоуровневый интерфейс, так как выигрыш от плюсов данного паттерна превышает затраты на его реализацию.
Model-View-Controller не был выбран, поскольку паттерн Model-View-Presenter оказался более оптимальным решением. Однако существуют случаи, когда стоит выбрать именно MVC. Например, в веб-приложениях, поскольку http работает на основе режима запроса и ответа, не всегда имеется возможность поддерживать состояние соединения. Следовательно, передача сообщений между Presenters в MVP и привязка между ViewModel и интерфейсом в MVVM не могут быть достигнуты, поэтому MVC - лучший выбор.
Таким образом, можно сделать вывод о возможности применения каждого из рассмотренных паттернов для разработки различных приложения с пользовательским интерфейсом.
Список литературы
1. Швец А. Погружение в паттерны проектирования. 398 с. URL: https://refactoring.guru/ru (дата обращения: 21.04.2021).
2. Гладких Д. Паттерны: MVC, MVP и MVVM. URL: https://www.outcoldman.com (дата обращения: 21.04.2021).
3. Паттерны для новичков: MVC vs MVP vs MVVM. URL: https://habr.com/ru (дата обращения: 21.04.2021).
4. Архитектурные шаблоны в ABAP: MVC, MVP, MVVM, MVA. URL: http://abap4.ru (дата обращения: 21.04.2021).
5. Паттерны разработки: MVC, MVP, MVVM, MVI. URL: https://habr.com/ru (дата обращения: 21.04.2021).
6. Паттерн MVVM. URL: https://professorweb.ru (дата обращения: 21.04.2021).
Информация об авторах Ликсин Сергей Сергеевич, студент, Пензенский государственный университет.
Лукошкин Павел Андреевич, студент, Пензенский государственный университет.
Шибанов Сергей Владимирович, кандидат технических наук, доцент, доцент кафедры «Математическое обеспечение и применение ЭВМ», Пензенский государственный университет.
Авторы заявляют об отсутствии конфликта интересов.
