Philosophy Of Zenject - mariaheine/Zenject-But-Wiki GitHub Wiki

One thing that is helpful to be aware of in terms of understanding the design of Zenject is that unlike many other frameworks it is not opinionated. Many frameworks, such as ROR, ECS, ASP.NET MVC, etc. make rigid design choices for you that you have to follow. The only assumption that Zenject makes is that you are writing object oriented code and otherwise, how you design your code is entirely up to you.

In my view, dependency injection is pretty fundamental to object oriented programming. And without a dependency injection framework, the composition root quickly becomes a headache to maintain. Therefore dependency injection frameworks are fairly fundamental as well.

And that's all Zenject strives to be - a dependency injection framework that targets Unity. There are certainly quite a few features in Zenject, but they are all optional. If you want, you can follow traditional unity development and use MonoBehaviours for every class, with the one exception that you use [Inject] instead of [SerializeField]. Or you can abandon MonoBehaviours's completely and use the included interfaces such as ITickable and IInitializable. It is up to you which design you want to use.

Of course, using a DI framework has some disadvantages compared to more rigid frameworks. The main drawback is that it can be more challenging for new developers to get up and running quickly in a code base, because they need to understand the specific architecture chosen by the previous developers. Whereas with rigid frameworks developers are given a very clear pathway to follow and so can be productive more quickly. It is more difficult to make huge design mistakes when using a rigid framework. However, with this rigidity also comes limitations, because whatever design decisions that are enforced by the framework might not necessarily be ideal for every single problem.