Использование архитектуры Composition root в Unity. Часть 1. Настройка проекта с нуля

Здесь есть единая точка входа и Dependency Injection

Единую точку входа увидел, но что касается DI, то этого я не увидел, как и задела под него.

Если используете рх, то не стоит смешивать подходы и делать так:

button.onClick.AddListener( () => _ctx.buttonClickCounter.Value++);

А еще, по хорошему, ReactiveProperty нужно освобождать.

Непонятно, зачем вам ctx в качестве valueType, если из этого не извлекается какого либо профита.

_ctx.buttonClickCounter.Subscribe(ShowClicks);

Тоже нужно освобождать.

Что мешает какому нить джуну вызвать в `CubeView` метод `Init` несколько раз, и наплодить подписок, которые в результате могут привести к весьма "забавным" багам?

В целом, на уровне дизайна - очень сомнительно.

Во первых, UI построенный на GameObject в Unity3d крайне ущербный из за своего перформенса. Следовательно если вы делаете что то, более менее серьезное, должны быть пулы и ресайклинг элементов UI.

Во вторых, как правило, вьюхи могут реюзаться 100500 раз, с небольшими изменениями в плане отображения и поведения. Другими словами, у объектов из пула должны поддерживаться возможность конфигурирования отображения и подмены поведения. Если вы конечно не хотите плодить в пуле объекты, у которых небольшие различия.

В третьих, если это типа архитектура, то должен быть какой то контракт, например для проброски "контекста". При такой "архитектуре" не получится делать коммоновские элементы интерфейса, типа списка вьюх. Придется каждый раз писать код для каждого кейса, как минимум что бы просетать контексты.

В четвертых, если работаем с управляемыми ресурсами, должен быть лайфсайкл менеджмент и защита от дурака. Например, при повторном вызове `Init`, предыдущие подписки должны автоматически подчиститься.

На самом деле это далеко не все, что можно было бы выделить, но коммент и так уже большой получился.

Не понятно, как масштабировать эту архитектуру. Хотелось бы увидеть код более сложного проекта, чем подсчет кликов на кнопочке. С несколькими сценами, физикой и 5+ экранами.

Очень интересное решение хотя и имеет подводные камне. Можно попробовать на похожих принципах встроить работу с ECS(не имеющие интеграцию с Unity/ну или имеющие). Entry Point порождает ECSWorld как Root и на него уже крепятся остальные сущности и через View создаются нужные GameObject для вывода результатов, так мы получим почти пустые GameObject'ы со скрытой логикой где-то в сущностях.

Добрый день.
Любопытная статья, но вы можете сказать, а зачем такая организация?
Какие плюсы и минусы?

Пока все что мне видно - это фанатичное стремление всем управлять из кода, не использовать синглтоны, потому что харам (ну то есть непонятно почему) и куча boilerplate кода.

Продолжение статьи можно почитать вот тут https://habr.com/ru/post/711140/

Привет, Костя).
Я рад, что ты придерживаешься, разработанного мной подхода к проектированию архитектуры и, что все больше разработчиков к нему приобщаются.
Так как передача подхода местами искажена, внесу комменарии со своей стороны, чтобы у твоего читателя не было путаницы:

• View - это не GameObject, а MonoBehaviour

• Presenter Model - не Presenter, а Presentation Model

• DisposableObject, зачем в твоем коде _unityObjects? В оигинале был AttachComponent, который отвечал за добавление Unity обьекта и не вошел в статью:

protected Object AttachComponent(Object obj)
{
	if (_isDisposed)
	{
		Debug.Log("disposed");
		return default;
	}
	if (!obj)
	{
		Debug.Log("can't add null object");
		return default;
	}
	if (_unityObjects == null)
	{
		_unityObjects = new List<Object>(1);
	}
	_unityObjects.Add(obj);
	return obj;
}

В моём профиле есть ссылка на TG канал, где я разбираю данный подход для разработки игр.