Неоднозначный 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 #геймдев #разработка #архитектура #рекомендация #статья #видео