IoC vs ECS для крупных Unity проектов. Какой подход лучше использовать в текущих реалиях?
===========================================================================================

 Добрый день!   

  

Подключился к крупному мультиплеерному проекту с использованием [Strange IoC](https://strangeioc.github.io/strangeioc/).   

  

Для новой версии проекта подбираем новые принципы/фреймворки/архтитектуру, и тут вопрос, подбирать что-то новое или продолжить работать со Strange IoC. Задача оптимизировать проект настолько, насколько это возможно.  

  

Для теста я создал пару мелких проектов и разобрался с работой Strange IoC, но успел обратить внимание на несколько "нюансов", из за которых может падать производительность в крупных проектах, а конкретно быстрорастущее количество команд и сигналов ( если мы говорим про подход с использованием Signals, а не Dispatcher в Strange IoC ).  

  

Поделитесь своим опытом работы с IoC при разработке Unity приложений, возможно у кого-то был опыт именно со Strange IoC.  

  

Также рассматриваем возможность перехода на ECS, но из за некоторых проблем с совместимостью текущих наработок - побаиваемся, возможно у кого-то также был опыт с ECS и есть примерное сравнение производительности подхода IoC vs ECS. 

 Вообще, довольно забавное сравнение, на мой взгляд.   

ECS обычно противопоставляют стандартному ООП подходу). Но я понял вопрос, вы, вероятно, хотите узнать насколько DI в ECS будет быстрее чем DI в стандартном стиле?  

Судить сложно, да и, пожалуй, не совсем корректно.   

  

Я не пользовался Stange IoC, но, полагаю, ECS будет в любом случае быстрее). И в DI, да и в целом, сам по себе. Но ECS, как бы, это не совсем про скорость. Скорость - это побочный продукт, приятный, но не основной.   

  

ECS про скорость разработки, удобство добавления новых фич, устойчивость к изменениям.   

Стандартная UECS пока ещё сырая, но есть много сторонних ECS фреймворков, которые дружат с Unity и вполне себе зрелые для крупных проектов.