0

I am reading this article about using DI inside ASP.NET Core @ https://learn.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-6.0 .. but i can not understand its benefit of providing abstraction level.

for example without DI, we will have those classes:-

public class MyDependency
{
    public void WriteMessage(string message)
    {
        Console.WriteLine($"MyDependency.WriteMessage called. Message: {message}");
    }
}

public class IndexModel : PageModel
{
    private readonly MyDependency _dependency = new MyDependency();

    public void OnGet()
    {
        _dependency.WriteMessage("IndexModel.OnGet");
    }
}

and with DI we will have those classes:-

public interface IMyDependency
{
    void WriteMessage(string message);
}
public class MyDependency : IMyDependency
{
    public void WriteMessage(string message)
    {
        Console.WriteLine($"MyDependency.WriteMessage Message: {message}");
    }
}
public class Index2Model : PageModel
{
    private readonly IMyDependency _myDependency;

    public Index2Model(IMyDependency myDependency)
    {
        _myDependency = myDependency;            
    }

    public void OnGet()
    {
        _myDependency.WriteMessage("Index2Model.OnGet");
    }
}

but at the end with DI or without DI if i want to modify the WriteMessage method, to accept 2 strings instead of one as follow:-

public void WriteMessage(string message,string message2)
        {
            Console.WriteLine($"MyDependency.WriteMessage called. Message: {message}{message2}");
        }

i will have to modify the related classes; without DI case:-

public class IndexModel : PageModel
{
    private readonly MyDependency _dependency = new MyDependency();

    public void OnGet()
    {
        _dependency.WriteMessage("IndexModel.OnGet","two");
    }
}

with DI case:-

public class Index2Model : PageModel
{
    private readonly IMyDependency _myDependency;

    public Index2Model(IMyDependency myDependency)
    {
        _myDependency = myDependency;            
    }

    public void OnGet()
    {
        _myDependency.WriteMessage("Index2Model.OnGet","two");
    }
}

so not sure how using DI will create an abstraction between the WriteMessage implementation and the classes which consume it.. or i am understanding DI and its benefits wrongly?

Thanks

4
  • The question doesn't really seem to have anything to do with DI, it seems to be about programming to an interface, defining contracts in a way which allows them to remain stable, which really depends a lot on having enough of an understanding of your requirements to be able to design the right abstractions in the first place. If your interfaces end up changing frequently, then the real problems are most likely rooted either in the understanding of requirements, or simply that the requirements themselves are unclear and prone to change. DI certainly can't help with this. Oct 31, 2022 at 23:34
  • @BenCottrell Thanks for the reply. but this is how MS is describing the DI as per the link i shared
    – test test
    Oct 31, 2022 at 23:47
  • FWIW I have been a .NET dev for a long time and I completely agree that the MS way of wiring up DI seems to me to be no better than just having some global functions available in the code.
    – GHP
    Nov 1, 2022 at 13:19
  • @Graham yes so it is hard to understand the benefits of using DI in ASP.NET core from their documentations, as seems the benefits are mainly coming form using Interfaces rather using DI
    – test test
    Nov 1, 2022 at 13:31

1 Answer 1

1

One of the primary benefits of using interfaces with dependency injection is the ability to easily mock the dependencies and make unit testing easier. Your test code merely needs to provide a non-functional object to stand in for the real thing so you can ensure the code you wrote in the controller does what you need it to. Without actually calling the classes you wrote to persist or retrieve data, you also avoid potentially corrupting your database with unit test data.

In some cases, you may have multiple implementations for the interface, and the interface simply defines the methods used to interact with the other implementations. The code using those implementations doesn't really care which one it is, and you can substitute the implementation based on subscription models or whatever other business reasons to do so.

Once you are used to the process, it's a lot easier to think through the interfaces and what needs to be done without worrying about how it needs to be done right then. The interfaces provide a means of defining the what so you don't lose focus on the code you are writing at the moment, and still be able to compile and run unit tests. You can go back later and implement the interface for a working system.

3
  • thanks . so seems you are mainly talking about the benefits of using Interfaces rather than DI? or i got your point wrongly? so what is DI doing . as we can use interfaces (which almost every developer use them) without having to use DI..
    – test test
    Nov 1, 2022 at 13:29
  • DI is wiring up the implementations you are using to the interfaces you are coding against. t avoids a lot of boiler plate code and builds the dependency tree in the right order on your behalf. I focused on interfaces because your comments seemed to suggest that was where you had the biggest dilemma. Nov 2, 2022 at 10:47
  • the example i gave was taken from Microsoft documentation regarding DI . where i can not see any benefits of using DI ..
    – test test
    Nov 2, 2022 at 12:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.