MVC в Unity. Часть 1. MVO

[ioleynikov]

К сожалению я не знаком с реализацией MVC в Unity но хочу рассказать как это делается в React.js. Эта система внесла очень существенное улучшение концепции MVC. Классическая схема предполагает, что модель передает изменения данных в представление и тем самым полностью нарушает принцип независимости компонент. В React представление автоматически отслеживает изменение состояний данных модели при помощи механизма событий и обновляет UI. Аналогично контроллер React следит за событиями UI и представлению нет дела до обработки действий пользователя. Это намного более строго обеспечивает независимость и позволяет разработчику модели полостью абстрагироваться от представлений. Если Unity MVC реализует подобный механизм, то это здорово.

[PLoveGames]

Да, это действительно так. В этой статье как раз такая ситуация. В следующей рассмотрю механизм взаимодействия с пользователем

[ioleynikov]

Я понял. Спасибо. Я сейчас думаю о некоей системе, которая реализует MVC в чистом виде. Разработчик модели данных знает только SQL и понятия не имеет о вьюверах, контроллерах, C#, JavaScript. Мыслит только в терминах таблиц реляций и бизнес логики. Дизайнер UI знает только HTML, CSS ну и готовые визуальные реализации таблиц, списков, деревьев. Вся забота о сращивании ежа с ужом ложится на контроллер, но у программиста есть компилятор логики с описания на английском, русском языках в код JavaScript React, Angular или C# Unity, .NET Core. Думаю, что такую систему можно будет построить с привлечением средств генеративных нейросетей ИИ. Надо просто правильно определить все интерфейсы и обучить нейросети как использовать API фреймворков . Ещё раз Спасибо, хороших выходных и Удачи!

[leni8ec]

Довольно хорошо написано, как для статей про MVC, где обычно любят излишне усложнять.

Также понравилось что показали какую именно проблему это решает.

Интересно будет почитать продолжение, спасибо.

[PLoveGames]

Спасибо. Следующая статья будет в таком же формате

[Bardakan]

много работал в MVC (objective-c, swift). Возможно я чего-то не понимаю, но вы сами выделили сущность View:

View - это логика, отвечающая за визуализацию и отображение данных.

Если другие компоненты напрямую не связаны с отображением в том же визуальном редакторе, то зачем им наследоваться от MonoBehaviour, добавлять SerializeField и т.п.? Или это связано с какими-то особенностями Unity?

[PLoveGames]

Да, это связано с особенностями Unity. Так как нам необходимы другие компоненты, например текст, то нам нужен объект, который сможет эти компоненты получить. В Unity проще всего это сделать через MonoBehaviour и SerializeField. И так как у нас идет взаимодействие с View(например, выключать и включать view) наследование от MonoBehaviour нам также подходит

[Bardakan]

не, подождите. Вопрос не про view. Почему у вас SerializeField в модели и контроллере?
Почему нельзя их оставить внутри view как входные параметры, которые задаются в UI редакторе, а потом передаются внутрь контроллера и модели?
И можете выложить пример проекта? Потому что то, что вы озвучили, выглядит так, как будто в UI редакторе будет каша из классов (для каждого mvc модуля в UI объект добавляется минимум 3 скрипта, которые еще и нужно связать между собой (тоже через UI), хотя это можно было сделать целиком в коде.

[PLoveGames]

Да, это действительно делается в коде. Можно в одном месте забиндить нужные данные. А потом их использовать. В такой системе и ваш вариант можно сделать. Это другая проблема - внедрение зависимостей. Ее в статье не рассматриваю

[Grave18]

В игре наверняка будут другие персонажи с механикой здоровья. Для каждого из них надо делать сразу 3 панели. А что если им не нужны панели? Тогда писать костыли с if конструкциями для конкретно их случаев

Для этого случая что мы конкретно должны делать, вынести view в интерфейс или использовать что-то еще?

[PLoveGames]

Привет. Разделить логику из View. И для каждой View написать observer, если это необходимо. Исходим из проблемы

[Wolfdp]

Я не сильно разбираюсь в Unity, поэтому уточнил данный подход у знакомого игродела. С его слов:

1. примеры больше похоже на MVP, чем на MVC

2. вью и контроллер ещё норм наследовать от MonoBehaviour, а вот модель -- уже не очень

3. лучше сразу идти в сторону MVVM, чтобы можно было менять значение в одном месте, и автоматически подтягивало в остальных

В целом глядя на код, много вопросов к подходу...

[Grave18]

Как пример использования MVVM - это Noesis gui, WPF-подобный фреймворк для создания интерфейса. Про MVP, MVC , по моему мнению, если ничего под интерфейсы не убирать и не использовать DI, то это обычное разделение одного класса на три, но по карйней мере получается разделить зоны ответственности, что уже не плохо.

[PLoveGames]

Да, фактически это применение принципа S из SOLID. Мы делим логику на ответственности. И за счет того, что есть похожие реализации этого деления, существует эта концепция MVC.