Let’s get into another sample to illustrate using the singleton lifetime and DI. Seeing DI in action should help understand it and then leverage it to create SOLID software.Context: The application is a site-wide wishlist where users can add items. Items expire every 30 seconds. When a user adds an existing item, the system must […]
Using the implementations – Dependency Injection
We can now use any of the two implementations without impacting the rest of the program. That demonstrates the strength of DI when it comes to dependency management. Moreover, we control the lifetime of the dependencies from the composition root.If we were to use the IApplicationState interface in another class, say SomeConsumer, its usage could […]
First implementation – Dependency Injection
The first implementation uses the memory cache system, and I thought it would be educational to show that to you. Caching data in memory is something you might need to do sooner rather than later. However, we are hiding the cache system behind our implementation, which is also educational.Here is the ApplicationMemoryCache class: public class […]
Revisiting the Singleton pattern – Dependency Injection
The Singleton pattern is obsolete, goes against the SOLID principles, and we replace it with a lifetime, as we’ve already seen. This section explores that lifetime and recreates the good old application state, which is nothing more than a singleton-scoped dictionary.We explore two examples: one about the application state, in case you were wondering where […]
Understanding guard clauses – Dependency Injection
A guard clause represents a condition the code must meet before executing a method. Essentially, it’s a type of code that “guards” against continuing the execution of the method if certain conditions aren’t met.In most cases, guard clauses are implemented at the beginning of a method to throw an exception early when the conditions necessary […]
Use_the_InMemoryLocationService – Dependency Injection
Next, we use the in-memory location service to compose the controller like this: var inMemoryLocationService = new InMemoryLocationService();var devController = new InjectAbstractionLocationsController( inMemoryLocationService); As we can see from the preceding code, we injected a different service into the controller, changing its behavior. This time, after calling the GetAsync method, the controller returned the ten Location […]
Injecting an abstraction in the controller – Dependency Injection
In this last controller, we leverage the SOLID principles, constructor injection, and, inherently, the Strategy pattern to build a controller that we can change from the outside. All we have to do to make the code flexible is inject the interface instead of its implementation, like this: using Microsoft.AspNetCore.Mvc;using Strategy.Services;namespace Strategy.Controllers;[Route(“travel/[controller]”)][ApiController]public class InjectAbstractionLocationsController : ControllerBase{ […]
Control Freak controllers – Dependency Injection
This first version of the code showcases the lack of flexibility that creating dependencies using the new keyword brings when the time to update the application arises. Here’s the initial controller that leverages an in-memory collection: using Microsoft.AspNetCore.Mvc;using Strategy.Services;namespace Strategy.Controllers;[Route(“travel/[controller]”)][ApiController]public class ControlFreakLocationsController : ControllerBase{ [HttpGet] public async Task<IEnumerable<LocationSummary>> GetAsync(CancellationToken cancellationToken) { var locationService = new […]
