Неоднозначный MVC: причины и следствия

Уровень материала: 🐥 #middle
Ранее я писал, что прохожу обучение на курсе от Unity Architect. Недавно была тема, посвященная MVC
. И упор был сделан не на очередной разбор очередной реализации, а на выяснение причин, почему существует такое разнообразие трактовок. Из этого вытекают и некоторые следствия, о которых не часто рассказывают, но которые находят место в практике.
Про разнообразие подходов 🛠️ :
Причина такого раздрая — «так исторически сложилось». Когда по принципу «глухого телефона» революционный много десятилетий назад подход дошёл до наших современных дней.
Подробнее с этим можно ознакомиться в длинном исследовательском материале из двух частей на Хабре: #1 и #2. Текст объёмный и сложный. Но увлекательный. Для вдумчивого чтения (а иначе смысла нет) стоит заложить на обе статьи где-то 1 час.
А один из примеров реализации в геймдеве я шарил в этом посте.
Следствие 1️⃣:
MVC
— это изначально история про взаимодействие с пользователем. Т. е. про UI. Соответственно, попытки затащить это в геймплей сделают из MVC
не MVC
(и даже не обязательно какой-то MVx
). Т. к. для удобства использования в геймплее эту штуку приходится адаптировать.
Следствие 2️⃣:
Как бы ни был «приготовлен» MVC
, кто-то обязательно скажет, что это неправильно. Или это не MVC
, а какой-нибудь другой MVx
. Это бесконечные бессмысленные споры, стоящие на противоречивых источниках.
Чтобы не маячить красным платком перед «искушённой» публикой, можно отойти от общеизвестного нейминга. Соблюсти идею разделения визуала и бизнес-логики, но назвать это иначе. Особенно легко это делается в геймплее.
Ведь задача — спроектировать всё хорошо, а не сдать экзамен по «эталонному соответствию канонам». Тогда на нападки в виде «но в MVx
же...» можно отвечать «а это не MVx
».
Следствие 3️⃣:
Эталонно View
и Controller
находятся на одном слое взаимодействия с пользователем. И в современных системах, где нет низкоуровневого кода по непосредственно рендерингу и обработке ввода, контроллер как-таковой не шибко нужен. Поэтому достаточно использовать только Model
и View
.
В качестве Model
можно подготовить специальную прослойку, типа Facade
, Adapter
или Mediator
, которая будет агрегировать внутри всю коммуникацию с необходимыми игровыми моделями и сервисами.
Например, нажалась кнопочка, медиатор из WalletModel
снял монетки, в StorageModel
положил конфетки, а у AdService
запросил показ InterstitialAd
.
В свою очередь View
будет отвечать за всю логику представления (кнопочки, формочки, генерация карточек, анимации прокрутки, заполнение прогресс-баров и пр.) и передачу событий в Mediator
.
Связку из View
и Mediator
я и в своей команде использую уже очень давно — это отлично себя показывает в проектах разных масштабов.
На каком-то из стримов K-Syndicate оговаривались, что используют двухуровневый шаблон и связующий слой тоже называют Mediator
. Не нашёл, на каком именно, но у них был большой классный стрим по MVx в целом.
————————————
#unity #gamedev #development #architecture #mvc #mvx #геймдев #разработка #архитектура #рекомендация #статья #видео