Комментарии 16
Экран - это цельный объект, в котором может быть много разных UI элементов. Например, окно прокачки персонажа - экран. Инвентарь - экран. Полоска прогресса производственного генератора - не экран, а вот окно с генератором и его настройками - экран. Экран сам руководит своими UI элементами: может их показывать, скрывать, менять у них настройки и тд
Слишком условное деление. Что если я хочу сделать экран в экране? Что если нужны модальные окна? Что делать с элементами вроде статичного меню которое всегда вверху или внизу? Что если в одном случае UI элемент является экраном, а в другом встроен внутрь меню?
Что за интерфейсIGameData ? В статье нигде не упоминается.
Зачем нужен не дженерик Bind(object model); и для чего вообще нужен BaseScreen который вроде как имеет в себе концепцию модели, но ничего с ней не делает? Выглядит как лишний уровень абстракции.
В чем вообще смысл всей этой свзяки с моделью через ViewModel, если по сути вызовы логики типа AddHealth() проксируются через аж 3 класса в нужный?
Как это все работает с юнит, интеграционным тестированием? C# не позволяет делать mocks для абстрактных классов, чем обусловлен выбор их а не в пользу интерфейсов? Какие элементы из MVVM планируется покрывать тестами?
Проблема с кастомными реализациями MVC, MVP, MVVP и прочими паттернами в Unity и не только, заключается в том что структура копируется без оглядки на смысл. Если делать столько слоёв абстракции, то нужно понимать, зачем они нужны.
Например, в Xamarin.Forms структура MVVM нужна для (и предоставляет) множество полезных фич, таких как Two-Way Binding. В вашем примере ничего этого нету.
Ответ, "потому-что так написано в англоязычной википедии по запросу MVVM" не является на мной взгляд достаточным.
Как по мне, выбор любых паттернов или фрейморков очень сильно зависит от нужд проекта. Не существует серебряной пули, которая бы отлично подходила всем. В 3D игре с экраном настроек и главным меню, требования к структуре UI совсем другие, чем в сложном 2D ui-driven проекте с сотней различных экранов.
Для игр с большим колиеством UI элементов, я советую начать с изучения Dependency Injection и IoC, эти концепции на мой взгляд довольно хорошо сочетается с ECS.
К парадоксу Рассела я не стремлюсь, поэтому экраны не содержат другие экраны в качестве элементов. Надо открыть что-то еще - вызывается новый экран. Надо держать внутренний UI элемент - никто не мешает. Статическое меню - все время открытый экран, проблемы не вижу. Если в одном случае элемент - часть окна, а в другом должен открываться отдельно, то можно его и использовать как элемент. Просто в одном случае он будет частью крупного экрана, а в другом будет отдельно для него сделанный экран, содержащий только его
IGameData выступает в роли модели, из которой можно брать кактие-то данные
Не дженерик Bind не нужен, согласен
Смысл в разделении. Если здесь это вызов в лоб, то в более-менее крупных экранах во вью модели будет происходит подготовка данных для обращения к модели, какие-то события аналитики и тд.
Модель покрывается юнит тестами, при желании вью модель. Так же можно замокать модель и прогнать и передать во вью модель
На дальнейшее отвечать уже не надо, полагаю
MVVM состоит из 3, но не совсем, частей:
Паттерн MVVM как раз и состоит из 3 частей (M - model, V - view, VM - view model), чего для самого паттерна достаточно, любые Binder, Controller и прочее - это уже дополнительные классы/модули, которые расширяют функционал MVVM.
Binder (биндер). Слой, помогающий связать вью и вью модель в автоматическом режиме. Почему-то совершенно игнорируется вики на русском языке, хотя, если верить английской версии сайта, это самый важный компонент паттерна, а сам паттерн можно называть model-view-binder.
Сам паттерн назвать Model-View-Binder? А смысл тогда использовать MVVM? Ответ весьма лаконичен: непонимание того, что есть Binder, не говорит о том, что мы используем другой паттерн, мы остаёмся также в пределах одного паттерна, только дополняем его функционал, делаем код более читаемым, разбиваем логику на части (легче исправлять небольшие файлы, чем один, но на "миллионы" строк)
---
В общем и целом, я согласен с @splatt, так как вы просто переписали Wikipedia, не понимая того, как это будет работать в отличных от ваших условиях и для чего это использовать.
Абстрактные примеры для того и абстрактные, что они дают самое поверхностное представление, но не заявляют, что так правильно и/или так надо делать всегда и везде.
Как насчет написать свою статью, если разбираетесь? Просто я на хабре, вроде бы, не видел еще ни одной статьи по MVVM на юнити, которую бы не захейтили.
А чем MVVM на Unity принципиально отличается от всех остальных MVVM? На каждый движок и фреймворк с UI отдельный туториал писать?
Тем, что юнити не заточен под этот фреймворк в том плане, что все его UI элементы это отдельные геймобжекты, у которых свои цикл создания и инициализации.
Понятие "заточен" - очень расплывчато. На Unity можно реализовать что угодно. Вопрос всегда в сложности реализации.
Реализация MVVM на Unity, это очень большая и сложная работа. Особенно если вы хотите получить что-то действительно рабочее и универсальное. Думаю именно по этой причине статей нет.
Вы всегда можете попробовать изучить имеющиеся фреймворки в asset store. Если есть действительно хорошие фреймворки их можно "купить" и поковырять.
Я делал свою реализацию MVVM с биндами и локализацией. Статья если что не о MVVM, а скорее просто презентация того что я делал.
https://habr.com/ru/post/717286/
И это тоже не первый MVVM фреймворк. Ранее я на харбе видел ещё одну реализацию, но мне она не понравилась т.к. для биндов там требовалось создавать новые кастомные контролы для UI Toolkit.
Очень слабо раскрыта тема MVVM. Сама система MVVM намного больше и шире.
На мой взгляд Microsoft сделали эталонную реализацию MVVM. Если интересно, можете попробовать поработать на Microsoft WPF, для более глубокого понимания MVVM и работы с этим подходом. Так же Microsoft держит свои исходники в открытом доступе, можете всегда поковыряться и посмотреть реализацию.
Для начала нужно понять, какие проблемы решает MVVM и чем отличается от других систем. Binding не является обязательной частью системы MVVM. Но правилная реализация Binding может дать большое приемущество MVVM перед другими системами.
Советую вам не зацикливаться на Unity и поработать с чем-то ещё. Unity очень специфична и имеет свою систему, в которой не всегда просто разобраться, как реализовать тот или иной паттерн.
Причем тут WPF? У человека в статье конкретика применения MVVM в рамках геймдева через движок Unity3d. Тот факт что MVVM для клиентского кода в рамках Unity слабо подходит, это другой разговор, но тем не менее.
Текущая реализация MVVM это просто визуализация информации с Wikipedia. Такая реализация принесёт больше проблем, чем пользы. Если вы этого не замечаете, то могу предложить вам тоже лучше ознакомиться с MVVM.
Расписать все проблемы достаточно сложно. Сама система очень большая и комментарий превратится в отдельную статью. В следствии этого, я просто предлагаю изучить MVVM реализованную от Microsoft в WPF. Там очень много классных решений, которые делают из MVVM достойную систему. Плюс исходники открыты, сиди изучай.
Не имею понятия на какие факты вы опираетесь, но MVVM в Unity прекрасно может работать. Я это говорю из личного опыта с очень крупными проектами. Как всегда, вопрос в реализации.
А есть примеры реализации mvvm в юнити, с которыми можно ознакомиться? Собственно, в статье я и упомянул, что здесь будет известный мне вариант, а на лучший из возможных. Так что хотелось бы увидеть, как правильно подходить к проектированию.
Если таких нет, то тезисы звучат как-то неубедительно, не находите? Особенно предложение пойти читать реализацию от Майкрософт. Всегда же можно будет потом сказать, что читатель плохо понял, если не смог адаптировать
Открытых реализаций MVVM в Unity я не знаю. Код с которым мне доводилось работать является собственностью компании. Тут в комментариях я уже предлагал попробовать найти на AssetStore фреймворк и расковырять его.
Верить мне или нет, исключительно ваше решение. Вы же учите материал не для читателей, а для собственного развития. Я просто порекомендовал попробовать посмотреть в сторону WPF MVVM, если хотите лучше понять систему.
Учу для себя, это правда, но в рамках обсуждения единственного на хабре туториала по MVVM на gameObject без сторонних пакетов оперировать к чему-то, что нельзя сразу взять в работу, до обидного бессмысленно. Так как на материал статьи я могу сразу кидать ссылку, зная, что все заработает, а вот на решения, требующие адаптации, уже нет.
Ну а что касается собственности компании, то можно же предложить хотя бы вна базовом виде обьяснить подход на хабре. Так и онбординг будет быстрее происходить, да и повысится вероятность того, что новый сотрудник уже работал с подходом. Я, собственно, так и сделал
Ну вся беда в том, что такие статьи могут увести условного новичка в дебри. Потом он придёт на собес и будет тебе что-то доказывать.
Как это происходит обычно. Прочитал статью, вспомнил паттерны, реализовал свой велосипед - сидишь довольный.
Но нужно использовать доступные и популярные решения, частично адаптируя их под себя. В компаниях так делают, как минимум потому что выгодно. Это уже отдельная большая тема.
Статья вроде не самая плохая. Авто показывает какой-то ход своих мыслей после изучения материла. Но нужен какой-то предупреждающий дисклеймер, о опыте автора в этой сфере и.т.д.
Я выше писал, что расписывать даже на базовом уровне MVVM в Unity - утомительно. Это большая работа, т.к. до MVVM нужно сделать большую "обёртку" для системы Unity.
Вариант Mvvm в Unity