DI in Asp.net core, abstract
I'm just now getting into the DI stuff in asp.net, I've used DI patterns before but only in xaml and windesktop stuff, and even then I never really understood it.
Having gone over the docks thoroughly and many a time... I'm starting to get a grasp if you could help me confirm the things i've gathered. I'm in the process of writing a bigger piece of code based on this, I'll put it up in review channel once I'm done.
things I've noticed:
DI is basically a global Object with a bunch of predefined interfaces: With the service-collection implementation at app level you define a collection of interfaces which all other elements of your code "could" depend on and instead of passing the object around you pass around the interface you depend on. You then provide the implementation at app level and you're done, asp.net resolves the interface to the object dependency at runtime.
The instantiation gets moved to startup.cs: With .net 8 startup.cs isn't a thing anymore, where you normally would run your singletons, factories and configurations which would have dependencies in the environment and change their implementation. Now it gets done in the appbuilder.Services.Add--(ConfigClass). In the config class you run your configs, which should be a jsonfile with configurations of the implementation.
move of imperative/boilerplate code from application logic: Without DI you're stuck doing configuration logic for each object either in your razor page or your controller. Like when your model has dependencies in some other REST-client so you run the request in the controller, when all you really want to do is to have it populated with the data. To avoid this you move the population logic and request instantiation and response handling to your DI container, and in the controller you can just run the interface function.
If i missed anything, or have some misconceptions type it please out 🙂
4 Replies
DI is basically a global Object with a bunch of predefined interfacesNo, I wouldn't say that. You can register classes or even instances just fine, not just interfaces. what you configure with
builder.Services.AddScoped and the other DI methods is a service collection. When thats built with builder.Build, it turns into a ServiceProvider
at its core, it has two methods: GetService<T> and GetRequiredService<T>
these allow you to create/get instances from the provider that was configured on the service collection. Thats it.
the reason this might seem magic is that ASP uses that service provider to resolve your controllers, or razor pages etcso it's more like a collection of elements which will be extended to the controllers. Something alike to object delegation in javascript prototypes? Where the would resolve the reference into the underlaying implementation with the help of the config, and return null of not found.(unless is called, which would throw instead)
yes
I dont know how JS works, so cant attest to that likeness, but otherwise yes
Solid, Thanks alot! This has been hanging over me for some time, will be good to finally put it into the ground. 🙏