Comments 6
Для небольших проектов без мультиплеера стоит рассмотреть очень простую альтернативу - Unity сам по себе довольно мощный DI контейнер, который сам резолвит зависимости между компонентами, префабами и ScriptableObjects. Это конечно не вся палитра инструментов, но в целом можно использовать SO как глобальные сервисы (Это основное, зачем людям нужны зависимости).
Не совсем понятно, зачем для этого SO?
Тут, скорее, SO было больше для примера. Как самый простой в использовании кейс. Вообще подойдёт любая штука, в которую Unity умеет сериализовать данные: SO, компоненты, префабы, сцены.
И, насколько понял, в этом сценарии уже рассматривается больше ServiceLocator, чем DI.
Как зависимость, которую вы настроите руками в сцен, а unity сама подставит.
То есть это буквально инъекция в поля, просто с некоторыми ограничениями (SO и префабы все же не прямые аналоги объектов от Di с разным ЖЦ)
С другой стороны, используя DI мы сталкиваемся с фундаментальными ограничениями - обычно объекты нужно конструировать через DI. Иначе DI просто используется как сервис локатор.
Но в Unity как минимум для View слоя есть своя система порождения и свое внедрение зависимостей (конструирование уровня из сцен / префабов / коммитов - по сути это live time система внедрения зависимостей)
Соответственно они немного конфликтуют и для конструирования объектов нужны какие нибудь костыли (спец методы, спец объект на сцене, спец хуки, экстра код), которые по сути сводят на нет удобство DI
В идеале DI предназначен делать так, чтобы объект не знал, что ему нужен DI - ему просто давали его зависимости. Чем больше обвеса (атрибуты, внедрения через поля, хаки для старта в unity объектах) - тем меньше толку.
Если в итоге DI требует boiler plate чтобы работать на уровне объекта (то есть знает про DI) - проще просто засунуть service locator в SO и доставать зависимость из него - код получится проще.
Согласен. Нет смысла тащить инструмент туда, где он не нужен, и пытаться забивать гвозди микроскопом.
Про самостоятельный резолв, возможно, слишком лихо написано — всё же Unity не из общей кучи зависимости собирает, а подставляет конкретно заданные зависимости в конкретно заданные места.
С глобальными сервисами тоже немного перебор. Всё же тут важен контекст применения: на определённых масштабах глобальные сервисы становятся проблемой, а не благом.
Но, в целом, да Unity, действительно, предоставляет довольно гибкие возможности по внедрению и замене зависимостей "из коробки".
Да, прямые зависимости на SO конечно кривенько и аналогия не совсем прямая.
С другой стороны любая другая система зависимостей аналогично требует костылей, производительности и хаков поверх.
При этом все равно сущности view уровня будут собираться через обычные SerializedField, поэтому использовать вторую систему и синхронизировать их вместе - тоже такое.
Вообще глобальное ограничение Di - это то, что ты неявно собираешь всю иерархию не через new, но через DI, иначе это по факту ServiceLocator
Но в Unity уже и так есть свои костыли для порождения игровых объектов и компонентов и хорошие средства для работы с ними.
Обзор DI-фреймворков для Unity