Inversion of Control(IoC) and Dependency Injection

Server Tombak
4 min readJan 30, 2024

--

Hi everyone, I hope you are all doing well and in good Health. Today we will be talking about Inversion of Control(IoC) and it’s relation with Dependency injection. “ IoC is a design pattern which inverts the flow of control. and it makes the app loosely coupled and maintainable. ”

DI and IoC?

Dependency injection is one of the implementation of Inversion of control. While we are developing a software, we are using different services together. For example in an e-Commerce Website basket service and payment service are connected and will be using together because we are paying the things that we have in our basket.😉

So how we manage to use different services together?

One of the important principle in the process of developing a software is the first principle of SOLID which is Single Responsibility. That’s why we separate our services. So we have operation in different services and we need to use them together. We are doing that by injection its dependencies. Check in the below picture: SmsController is using sms services via injection in SmsController’s Constructor. There could be more services that we use in SmsController we would just inject them with the same way.

sms service Injection in sms controller

Dependency injection is one of the way for IoC. We are injecting the service’s interface so we are injecting the base type. We are doing that because in case of any new implementation we will not need to change the constructor’s dependency we will be just updating the part that where we say our program to use the new implementation class for the interface. Like below picture I am saying to editor(In .Net) to use FirstService class implementation ininjections of ISmsService interface.

So the software’s needs might change by the time and I may need to create a SecondService implementation class and in that case I will create a new service and implement ISmsService and update the Above code with the below. I did not need to change the parameter interface to say the program to use the new created service class. The advantage is; I did not need to change the part that I inject ISmsService in my SmsController and other parts that we may need to use ISmsService interface. That’s how it’s loosely coupled.

The whole Code in .Net

Lets make it little bit more clear with the whole code. As you already guess the example is about adding SMS service in our project. 😊


public interface ISmsService
{
void SendSms();
}


public class FirstService : ISmsService
{
public void SendSms()
{
Console.WriteLine("Sms sending by first Service");
}
}


public class SecondService : ISmsService
{
public void SendSms()
{
Console.WriteLine("Sms sending by second Service");
}
}


[Route("api/[controller]")]
[ApiController]
public class SmsController : ControllerBase
{
private readonly ISmsService _smsService;
public SmsController(ISmsService smsService)
{
_smsService = smsService;
}

[HttpGet]
public IActionResult Get()
{
_smsService.SendSms();
return Ok();
}
}

As you could see in the code that we have an interface which has a method for sending SMS. And we have added two different SMS service for that operation. Which class implementation will be using in that example?

builder.Services.AddScoped<ISmsService, FirstService>();

The one which we have configured with framework which is FirstService. And if we change it with SecondService then the second implementation will be working on the app.

builder.Services.AddScoped<ISmsService, SecondService>();

So thats how it makes the app lossely coupled as we said. If we want to change it then its quite easy. Lets assume that now we have a new SMS service that we need to add to the app. The only thing we need to do is just implement ISmsService with our new service.

  public class ThirdService : ISmsService
{
public void SendSms()
{
Console.WriteLine("Sms sending by third service");
}
}

Now we will say by framework method that we want to use third service anymore.

builder.Services.AddScoped<ISmsService, ThirdService>();

That will be what we will see when the app works.

The main thing was sending the interface as the constructor’s parameter and handling which implementation class will be used with framework.

That was all that I wanted to share. If you liked and think that it was useful don’t forget to claps and follow. Happy Coding :)

--

--

Server Tombak
Server Tombak

Written by Server Tombak

Software Engineer with a relentless passion for learning and sharing knowledge. Join me on my journey to explore the ever-evolving world of technology.

No responses yet