Dependency Injection was always a tricky concept and hard to understand for me when I started my career.(Well, in fact even in college days this was the chapter that I left on optional.)
Later, after working on .NET web applications and I understood the basics of Dependency Injection, But I still had some gaps. So, when I got a chance to explore more about this concept, I jumped right in and thus sharing my experience via this blog.
.NET Web Applications are based on C# which is in turn based on OOP. So this means classes and objects…..lots of classes and objects. These Classes and Objects depend on one another. With an increase in time the number of classes and objects will increase, causing complexity to increase if not implemented properly. Also with increasing complexity the maintenance will be difficult.
Normally, we will have a interface and a service class that implements that interface a constructor that has this service class as attribute. Like below,
Application Execution wise there’s no big problem with the above code. It will execute fine. But you see here, there’s a tight coupling created. Meaning objects creating another objects on which they depend on. With the increase in the lifetime of an application this kind of hard coupling is gonna increase.
Dependency Injection addresses this issue. DI states that components – objects shouldn’t create objects they depend on, instead they should be passed to them. Thereby reducing the tight coupling, increasing maintainability etc. There are multiple ways to do this.
- Constructor Injection
- Property/Setter Injection
- Method Injection
The most commonly used approach is Constructor Injection, where we pass the dependencies via constructor thereby allowing them to be used anywhere within the class.
Sitecore Default DI is Microsoft DI. So, we need a ServiceConfigurator where we can register the dependencies which can be passed on to the controller.
When we inject a dependency there are ways in which their lifetime can be set.
AddTransient – The services are created each time they’re requested.
AddScoped – The services are created once per client request.
AddSingleton – The services are created for the first time they are requested and then every subsequent request will use the same.
We need to register this Service Configurator via config file like below.
We can also register a service from config directly . We can check the dependency registration – service configurations via,
/sitecore/admin/showservicesconfig.aspx
So it may seem we have done everything required. Let’s give it a spin.
We have done almost everything. Created Interface->Service Class->Controller->Registered the dependencies in Service Configurator->Passed the dependencies via constructor controller. But still we get the above error.
This is because for the controller the dependencies were not getting passed. Which means we still have one action pending. Which is registering the controllers. We need to register every controller that consumes the dependencies.
We can also get the dependencies using Service Locator. If you don’t have the option of passing the dependencies via Constructor Injection then getting the dependencies via Service Locator is the other option.
Regarding Controller registration, instead of doing them individually, thanks to Kam Figy’s code they can be registered all together based on the assembly. FYI
Now, we can register new services that will be developed during the lifetime of the web application in the service configurator and use them in the controller. This improves code maintenance and reduces tight coupling. This also enables us to implement better unit testing. Say we have Rest API related implementation. When we write unit test methods they can’t call actual API. In such cases mock response needs to be used. When can have some config keys where we can decide when to use actual implementation and when mock implementation. And the actual or mock implementation can be passed as a dependency via Service Configurator.
Sitecore Blog 