[RESOLVED] Dependency injection - some explanation

I'm allways confused about term "dependency injection".

Let's take a look at these two examples:

1.) Constructor injection

Code:

---

public class SomeClass
{
      private readonly Class1 class1;

      public SomeClass(Class1 _class1)
      {
          class1=_class1;
 
        //....
      }

}

---

2.) initializing instance in constructor

Code:

---

public class SomeClass
{
      private readonly Class1 class1;

      public SomeClass()
      {
          class1= new Class1();
 
        //....
      }

}

---

Now I'm wondering:

- why is example 1.) considered to be a dependency injection and example 2.) not ?

- what are differencies between them ?

- what are pros/cons of using each?


I'm hoping for a simple answer, since I'm a newbie in WPF. Thanks in advance :)

In both cases the SomeClass object is dependant on an instance of Class1, in the second case it is hard coded to use a specific instance of Class1 while in the first case you are going to provide an instance at runtime - you are injecting this dependency.

Your scenario doesn't really make much sense however as in both cases you are probably dealing with exactly the same Class1 instance, Dependency Injection is normally used when you want to pass in a different thing at runtime - it heavily relies on the concept of Polymorphism.

A better example might be a situation that uses an interface or similar e.g.

Code:

---

public class DataStuff //ignore low quality name
{
private IDbConnection _connection;

public DataStuff(IDbConnection connection)
{
    _connection = connection;
}

public void Dummy()
{
 _connection.Open();
 IDbCommand command = connection.CreateCommand();
command.CommandText = "SELECT @@version";
return (string)command.ExecuteScalar();
}
}

---

This class accepts any IDbconnection implementation and really doesn't care what.

Elsewhere in the application you would be using this class and you would be providing a valid implementation of this IDbConnection dependency e.g.

Code:

---

public void Sample()
{
IDbconnection conn = null;

if (<some condition>)
{
conn = new SqlConnection("....");
}
else
{
conn = new OleDbConnection("...");
}
var c1 = new DataStuff(conn);
c1.Dummy();
}

---

In this case the calling code is responsible for creating the dependency and can make a decision about exactly what type of connection to work with, the DataStuff class never knows or cares.

The idea being DI is it makes the classes more open and a lot more testable.

Often you would be using DI in conjunction with another framework such as NInject or similar which would manage the mapping of types etc.

Often times, It's not even your code that provides the arguments to the constructor. Enterprise grade apps generally use an IoC (Inversion of Control) container to provide instances of a required service. Your service types have constructor parameters that are interfaces and you configure the IoC container to tell it how to realise those interfaces, which may be concrete types or web service endpoints. An example of this is in ASP.NET MVC apps. You can declare constructors in your controllers with parameters and then configure an IoC container to provide arguments for those parameters. You never actually call the constructor of a controller and yet each one created has its dependencies injected via the constructor by the IoC container. If you want to completely change how all those arguments are provided, you can simply reconfigure your IoC container and the controller code remains unchanged.

Hi PlausiblyDamp,

thanks for response.

I know about interfaces and how to use, but so far I didn't quite need to use them. As you said, I allways use same instance of Class1 in my viewModels.

So in terms of performance I can use 2.) example as well, no difference at all ?

I'm asking this because I use ViewModel first approach (MVVM), and sometimes code get's ugly when calling like new SomeClass(new Class1()). Specially when I need to open a new Window with same datacontext of ViewModel...

Quote:

---

Originally Posted by jmcilhinney

Often times, It's not even your code that provides the arguments to the constructor. Enterprise grade apps generally use an IoC (Inversion of Control) container to provide instances of a required service. Your service types have constructor parameters that are interfaces and you configure the IoC container to tell it how to realise those interfaces, which may be concrete types or web service endpoints. An example of this is in ASP.NET MVC apps. You can declare constructors in your controllers with parameters and then configure an IoC container to provide arguments for those parameters. You never actually call the constructor of a controller and yet each one created has its dependencies injected via the constructor by the IoC container. If you want to completely change how all those arguments are provided, you can simply reconfigure your IoC container and the controller code remains unchanged.

---

I've read about that too, unfortunally I haven't really tried that in any of my project so far.

As said, I'm a newbie in WPF, and current project I work on is my first MVVM app. Any I don't use any of popular frameworks (Ninject, Caliburn Micro etc.).