MVC и MVP: как избежать технического долга в проектах на Unity

MVC и MVP: как избежать технического долга в проектах на Unity

https://researchandprogram.blogspot.com/2026/02/mvc-vs-mvp-for-ruthless-unity-developer.html

В статье обсуждается важность использования архитектурных паттернов MVC и MVP в разработке игр на Unity для избежания технического долга и упрощения поддержки кода. Автор утверждает, что монолитный код и чрезмерное использование MonoBehaviours приводят к проблемам в дальнейшем, и предлагает применять модульный подход.

В общем базово на самом деле статья ни о чём. Без архитектурных паттернов писать плохо, с ними хорошо. Краткое описание MVP и MVC без примеров. Но о чём я захотел написать по этой теме? Я недавно попробовал прикольную связку. Model->Controller->ViewModel->Presenter->View

По сути у меня есть модель, с ней работает контроллер. Контроллер описывает бизнес логику (и он внутри разбит на процессоры логики и через группу интерфейсов). Презентер дергает контроллер по события UI, контроллер при обновлении стейта передает вью модел в презентера, а он дальше распихивает их по View. И это оказалось довольно удобно по двум причинам (хотя и не особо быстро, но в контексте это неважно).

Первая причина, потом из этого паттерна невозможно выбраться. То есть обойти это флоу в основном модуле ну просто невозможно, там доступ к модели никак по-другому не получишь, не написав явный костыль со статикой. Поэтому всё подчиняется этим законам, и если кого-то пустить в проект, то по дифу сразу будет видно, кто вышел за рамки паттерна.

Вторая причина, это так чётко разделяет логику. В основном благодаря формированию ReadOnly ViewModel становится невозможным изменить модель в обход обращения к презентеру и действий в контроллере. Так как контроллер это не монобех, а просто шарповый класс, то отрезав презентера и вью можно навесить любой другой интерфейс обращения. Хошь апи поверх вешай чтобы играть и выноси логику на сервер, хошь играй текстом в телеграм боте.

В общем надо будет набросать какой-то пример, который не коммерческий, с демонстрацией этого подхода. Это конечно не совсем прямая абстракция как я люблю, там нужно немного вкурить, но как паттерн мне понравилась. Конечно при возможности нужно обсерверы (обновление модели и вью модели) декомпозировать или сделать реактивными. Так как сейчас при обновлении стейта модели она по сути отправляется целиком. Но в пошаговом геймплее это не особо то и важно на самом деле. Просто помню, когда я всё делал на реактивных пропертях, и изучал GraphQL для такой же логики взаймодействия с беком по сути, то там данных гонялось поменьше.

#новости