Home/ Questions/Q 6658825
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T01:57:31+00:00

Currently I’m trying to understand dependency injection better and I’m using asp.net MVC to

  • 0

Currently I’m trying to understand dependency injection better and I’m using asp.net MVC to work with it. You might see some other related questions from me 😉

Alright, I’ll start with an example controller (of an example Contacts Manager asp.net MVC application)

public class ContactsController{

  ContactsManagerDb _db;

  public ContactsController(){

    _db = ContactsManagerDb();

  } 

  //...Actions here
}

Allright, awesome that’s working. My actions can all use the database for CRUD actions. Now I’ve decided I wanted to add unit testing, and I’ve added another contructor to mock a database

public class ContactsController{

  IContactsManagerDb _db;

  public ContactsController(){

    _db = ContactsManagerDb();

  }

  public ContactsController(IContactsManagerDb db){
    _db = db;
  }

  //...Actions here
}

Awesome, that’s working to, in my unit tests I can create my own implementation of the IContactsManagerDb and unit test my controller.

Now, people usually make the following decision (and here is my actual question), get rid of the empty controller, and use dependency injection to define what implementation to use.

So using StructureMap I’ve added the following injection rule:

x.For<IContactsManagerDb>().Use<ContactsManagerDb>();

And ofcourse in my Testing Project I’m using a different IContactsManagerDb implementation.

x.For<IContactsManagerDb>().Use<MyTestingContactsManagerDb>();

But my question is, **What problem have I solved or what have I simplified by using dependency injection in this specific case”

I fail to see any practical use of it now, I understand the HOW but not the WHY? What’s the use of this? Can anyone add to this project perhaps, make an example how this is more practical and useful?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The first example is not unit testable, so it is not good as it is creating a strong coupling between the different layers of your application and makes them less reusable. The second example is called poor man dependency injection. It’s also discussed here.

    What is wrong with poor man dependency injection is that the code is not autodocumenting. It doesn’t state its intent to the consumer. A consumer sees this code and he could easily call the default constructor without passing any argument, whereas if there was no default constructor it would have immediately been clear that this class absolutely requires some contract to be passed to its constructor in order to function normally. And it is really not to the class to decide which specific implementation to choose. It is up to the consumer of this class.

    • 0