Best Practices of Dependency Injection in ASP.NET Core

ASP.NET Core, a cross-platform, is initially released by Microsoft for designing lightweight, modular web-based, IoT, cloud applications and for building the back-end services for mobile scenarios. The ASP.NET Core development is a promising framework for supporting side-by-side configurations. Among these advantages, another benefit which standout ASP.NET Core from others is its fierce support for DI (dependency injection), a technique for reducing the coupling in the application, making it flexible and ease the procedure during the testing of an application.

Wikipedia states, ‘DI’ is a design pattern for passing dependency object to a dependent object’’. And according to Stackoverflow, the object doesn’t contain hard code prerequisites; therefore we can inject or implement a new object (by creating new dependency) to those objects. The extensive documentation generated by Microsoft explains that ASP.NET Core is an ideal practice for OOP and web developers to implement dependencies. Here are the top five valuable reasons for injecting dependency for dependent objects;

• High-level IoC (Inversion of Control) between classes and dependencies.
• Easy testing, maintenance by loose coupled modules (reducing direct instantiation).
• Shutting-out bugs and memory leaks.
• Overcomes threading and multi-threading problems.
• Effective way of designing web services.

Up to this point, we’ve discussed brief overview of ASP.NET Core, DI, and now coming back to our topic let’s discuss what are the best practices of dependency injection in ASP.NET Core;

Types of Dependency Injection

In general, dependency injection revolves around three classes; client, service and injector class, whereas the injector class conventionally carries three types of injection for injecting services from service class into client class. But here the most important thing is the selection of design pattern; you’ll get an idea after reading the following explanation;

Service Locator

Service locator is comparatively old design pattern but still have some solid reason to implement injection. It instantly introduces singleton registry, which is responsible for service interface. As a result of this implementation of service interface, decoupling of dependencies becomes easy.

Note

• But due to its undeclared nature, it is not easy to understand and view the dependencies, resulting in hard testing.
• Your application might become bogus and complicated, if you resolve dependencies in the service locator.
• Creates scalability problems in contemporaneous atmosphere.
• It is better to define a contract for finding run-time errors; otherwise it will introduce changes while running the code.

Constructor Injection

In constructor injection, injector supplies dependencies (or services) to dependency (client) through constructor class and by using constructor properties. It is the finest approach as compared to other design patterns because it reduces dependencies between components. Furthermore, it avoids the circular dependencies and imposes the order of initialization. As it fixes the order of injection, it eases the process of instantiation.

Note

• Construct dependency only through service constructor. In this way, services can’t be constructed out of the constructor.

Property Injection

Writeable properties are used by property injection to execute the injection mechanism. In other words, a third party is used to implement dependency to the client class because ASP.NET Core’s container doesn’t support property injection.

Note

• Use this for creating only optional services. So, services can run without the involvement of these dependencies.

Do you want to learn DI through programming concepts and examples? Start your web development with Ansi ByteCode and let us do the rest. Browse our services and tell us what are you looking for.