0

I want to know in detail about the DI container of .net Core. if suppose we have a hundred number of classes and respective interfaces and I have registered all dependency in my startup.cs file. then my question is which one is true? a) all hundred instances will create startup time because I have mentioned all dependency in startup.cs. b) only those instances will be created at run time which is defined in the constructor.

Ankit Rawat
  • 1
  • 2

2 Answers2

4

It depends somewhat on the lifetime, but generally, they're instantiated as needed. For example, if you inject something into a controller, then when that controller is activated, the dependencies it has (defined in the constructor) are instantiated, and any dependencies those dependencies have are instantiated, etc. The exception would be something with a singleton lifetime. It would be instantiated the first time it's required, and then obviously reused over and over again thereafter.

Long and short, no, not all 100 services are instantiated at app startup, unless all 100 services are somehow used during app startup (causing them to need to be instantiated).

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • thanks a lot for your answer. that means if I am using transient lifetime then option **b)** is true. – Ankit Rawat Apr 15 '20 at 15:10
  • Objects with transient lifetimes are *always* instantiated every time they are injected, and disposed as soon as that code goes out of scope. – Chris Pratt Apr 15 '20 at 15:12
  • and also one more question, if I use DI in my new project architecture, the project is going complex for the new developer, like create interface, class and also mapping these in a startup.cs file. what is your point of view according to the same? – Ankit Rawat Apr 16 '20 at 10:51
  • It's not complex; it's good app design. DI as a term is used incorrectly most of the time. The injection part is a function of the top-level application; how it satisfies dependencies. What's really important is inversion of control: having functionality injected, instead of defined in class. – Chris Pratt Apr 16 '20 at 11:44
1

Basically, you need to imagine it as a list of services which are being registred in your startup.cs file and will be used accordingly with the execution of your application.

For this, you have ways to inject them, for example,(and the most used one in my opinion), through constructor injection. This said, we can now talk about lifetimes associated with them. I will succinctly express them:

AddSingleton: For each HTTP request you make, the same instance will always be used, in other words: always the same instance injected from the container.

AddScoped:A new service is instanciated with each HTTP request, but is only used within the scope of that request in the "different places" of your application.

AddTransient:For each HTTP request a different instance will be used and a different instance is injected in the "different places" of your application.

As for your title question, well, dependency injection is a way to simplify the instantiation of your dependencies since it will be the framework itself doing the "dirty work".

Miguel Ferreira
  • 325
  • 1
  • 15
  • Thanks for the reply and explanation about these three methods, in my case where I have to build rest APIs (like login, registration, get user list/simple get and post APIs) then which method is suitable to us? – Ankit Rawat Apr 16 '20 at 12:21
  • It really depends on your implementation and specific case. I recommend reading this [post](https://stackoverflow.com/questions/42608918/what-are-the-practical-scenarios-to-use-iservicecollection-addtransient-iservic) , I'm sure you will find an answer here :) – Miguel Ferreira Apr 16 '20 at 12:58
  • after reading this post, the transient is useful in my case, because each API gets their own context instance and also can run in parallel. that means transient is best for stateless services – Ankit Rawat Apr 17 '20 at 02:52