Hi.

Dependency Inversion is an issue that dependency injection is known as best solution for it, as all the dependencies are solved at project root in application startup.

the question is unity game has not single point of dependency. some dependencies are at code. some in editor(inspector, scriptable object, etc…) there are many points and many contexts including game object, scene, project and…

i believe using DI frameworks like can make things worse instead of better. my reasons:

1- controlling dependencies in contexts and container classes are hard.

2- logic in games are not something strict and it get changed through times through A/B testing etc…

3- most of DI frameworks use reflection to find dependencies at runtime that is not performant.

The better question is, whats the alternative in Unity? Using singletons, or FindObjects everywhere is definately not gonna improve points 1) and 2); and DI can be very helpful compared to having to link tons of managers all over the place (which you sometimes cannot de ie. when having a master-scene approach).

As for the performance-standpoint, yeah, sure, but unity already bleeds performance everywhere and unless you are really starting to see load-time increases in the multi-second levels then I would rather pick the middle-ground approach that is going to make my workflow smoother without being a total clusterfuck like singletons.

@Juliean let me explain more.

in an ASP Core Program you have a IActionResult Request Handler. Maybe You have a Class that you need to New to make and instance and call its functions, properties, etc. DI Container Simply Can Resolve this for you as single, as Transient, as etc…

in unity you have to say exactly what instance of that class im going to need. same component on my gameObject, on the object in my collistion, or single class in the scene as manager.

resolving all of these can cause you more contexts, more lambda search expressions in container class or… i believe you can simply get component by interfaces instead of concretions and you can simply understand what are you doing instead of reading more amount off code to see what is going on. its still test friendly and you can write mock,.. on it. am i right?

maybe DI in simple UI based games is helpfull but im against it on big projects with many different types of dependencies

I haven't used DI outside of Unity so I cannot really comment on how it compares. I also haven't done mock-testing much anyhows so I don't have an opinion here. I can kind of see your point and don't necessarily disagree with it; though I wouldn't come to the conclusion that you should not use DI in Unity for big projects. I mean, I personally despise unitys core-desing in many ways and in my personal engine that I use outside of work I go wastly di fferent routes (while I do not use much in terms of automatic DI I do use Dependency inversion all the time); but for within Unity after using Zenject for a year I would definately use it compared to most other solutions that exist within Unitys ecosystem, especially the larger the project gets.

My general opinion to this topic is, “it depends” haha

Dependency injection can be useful in terms of if the absolute implementation is unclear at a certain point in development. This may have different causes like loading a specific implementation of something depending on the platform or display type we're currently running on or if we want to decouple code modules from each other. On the other hand running fixed dependencies is also a valid case in game programming and I often see people abstracting things away that is totally insane to do so. It simply is code bloat when you write an interface that is unlikely to change the base implementation of code, for example in an utility library that will never be integrated by code rather than assembly.

Unity's main issue is the design and the not entirely ECS but also not OOP approach they run. In a pure ECS environment like they try to introduce more and more with DOTS, you don't care of classes and so dependencies anyways. It get's complicated with “legacy Unity” only because “Components” don't just have properties but also code they can execute which somehow violates the ECS design (logic has to stay in Systems)

Shaarigan said:
Unity's main issue is the design and the not entirely ECS but also not OOP approach they run. In a pure ECS environment like they try to introduce more and more with DOTS, you don't care of classes and so dependencies anyways. It get's complicated with “legacy Unity” only because “Components” don't just have properties but also code they can execute which somehow violates the ECS design (logic has to stay in Systems)

I haven't had the chance to play with ECS in unity, but if its anything like any other ECS then I'm not sure how good of an replacement for unitys old component-based system it really is. In my opinion, ECS is not the best solution for building specialized gameplay-scripts (something like a certain object which requires certain conditions to use, performs a very specific set of actions when used etc…). For that kind of stuff, I do prefer a more OOP-based approach whether its unity or my own engine, while reserving ECS for the features that are more generalizable.

I think ECS is a generic solution for things you frequently do in a game. Collision checks, AI, something. The benefits of ECS is that you could add behavior to objects without editing the code and you can start to parallelize your game systems super easy. If you have the need for more specialized things to go on, then yes, an ECS approach would be a pain here.

So why not use both