Комментарии 6
Мне в целом нравится архитектура, когда префабы – это View, компоненты – View-Model, а Scriptable Object – модель.
Непонятно, что вы имеете в виду под термином "компоненты". В Unity компонент - это, по сути, любой скрипт, навешиваемый на GameObject, т.е. наследуемый от MonoBehaviour. Префаб - это прототип некотого GameObject-а, который содержит 1 или более компонентов. Про "Scriptable Object – модель" - тоже непонятно, по тексту ничего не нашел, как и про MVVM, которая упоминается в самом начале, но дальше тоже ничего. Т.е. ваше объяснение префаба в терминах MVVM в самом начале вносит путанницу в терминологию Unity и вызывает вопросы, но никак не раскрывается дальше.
Наследник Monobehaviour навешиваемый на GO — это и есть компонент в данном контексте. И можно писать в таком стиле, что данные компоненты будут View-Model. Можно писать в другом стиле. Я скорее не понял суть вопроса :) Есть такой стиль архитектуры для проекта. Это не раскрывается, потому что как в юнити пишутся разные архитектурные схемы, почему любой крупный проект это всегда гибрид, и где лучше реактивный подход, а где другой — это не тема статьи :)
Можете не объяснять, т.к. действительно не тема статьи, но у меня с вашего описания возникло такое рассуждение, что если префаб - это ничто иное как GameObject, тогда любой GO - это тоже View. Если любой компонент - это ViewModel, тогда чистый View - это голый GameObject (пускай Transfrom не считается), получается, все View-префабы - динаково пустые GameObject-ы :)
Смотрите. Я безо всякого, просто правда не понял суть вопроса :) Не совсем. Префаб GameObject лишь с точки зрения кода, а с точки зрения конфига нет. Так как он сериализует все параметры висящих на нём компонент и т.п. ViewModel же осуществляет биндинг этих данных в код для проброса грубо говоря, как в том же самом xaml в UWP. Ну то есть GameObject — это бидинг по сути, как мы из кода обращаемся к конфигу. Так как он (конфиг) хранит все параметры и все ссылки на компоненты. Так как с точки зрения самого кода можно пойти ещё глубже до понятия самого скелетного скелета в Unity, это UnityEngine.Object, который обобщает вообще все виды объектов в редакторе.
Ну то есть если вы откроете именно файл с расширением .prefab, там же будут не только данные о трансформе, но и ссылки на все компоненты и что важно их параметры. Поэтому .prefab != GameObject. Класс GameObject можно воспринимать как удобный биндинг, который позволяет из кода навигироваться по ViewModel, задавая View более сложные поведения. Но View он не является. На примере пользовательского интерфейса, ViewModel — это Transform, Image, Button, TMP_Text. Если расписывать в целом схему, то GameObject опять таки тут будет обобщающим биндингом для доступа к этим компонентам, которые являются визуальной частью биднящую параметры отрисовки к модулю рендера, то есть той же ViewModel. И тут даже нет конфликта логики, так как View всё ещё остаются параметры записанные в виде текста (ну или бинарной информации) в файл .prefab. Проще всего это понимать просто через UWP и xaml, так как по сути там всё немного прозрачнее. Тут просто Unity текстовый конфиг заменило на решение в котором во главе стоит визуальный редактор)
Надеюсь понятно объяснил)
Думаю, я понял вашу идею, но мне, видимо, непросто воспринимать Unity через призму MVVM. Всякий раз, когда пытаюсь это сделать, чувствую, что расходую кучу мыслительной энергии на построение ментальной модели, которая никак не поддержана ни редактором, ни движком, поэтому падает продуктивность, проект становится более путанным, сложным для восприятия. Для себя лично пришел, что MVVM это не про Unity (а может и не про геймдев), что это больше для формочек. Во ViewModel есть "зависимые" свойства, которые уведомляют View через "связывание" об изменении своих значений. XAML заточен под MVVM, хорошо читаем, концепция связывания хорошо воспринимается через визуал, как и разделение View и ViewModel, чего совсем нельзя сказать об YAML. В Unity сложно однозначно определиться, является ли компонент View или ViewModel. По мне, так Transform - это чистый View, также, например, как какой-то XAML-компонент, отвечающий за положение панели относительно родителя, у которого есть Left, Top, Width, Height, к которому подвязывается ViewModel.
Это просто иллюстрация к тому, что не надо забивать на то, как организовано View, что в проектах я вижу слишком часто) Некоторые не пользуются префабами как View) И пишут в стиле андроид разработки без XML :) Чисто code-first интерфейсы. А есть такой подход где наследники SO — это модель, компоненты наследники Monobehavior — это View-Model, а префабы — View. Получается стиль почти написания UWP приложений. Ток на других форматах :)
Советы по работе с префабами в Unity