public class Invoice
{
public int invoiceId {get;set;}
public DateTime InvoiceDate {get;set;}
public Supplier SuppliedBy {get;set;}
public Customer BilledTo {get;set;}
public List<LineItem> LineItems {get;set;}
In above code, Supplier, Customer and LineItem are separate classes. It appears that instances of these classes are being injected through properties into an instance of the Invoice class.
We could have also passed these instances to the constructor of Invoice class using the second constructor and still have dependency injection.
My question: Is above code an example of DI (Dependecy Injection) in C#?
.NET forums are moving to a new home on Microsoft Q&A, we encourage you to go to Microsoft Q&A for .NET for posting new questions and get involved today.
UPDATE:After Mike's answer, I am posting this update. The code snippet in this post, with or without interfaces is DI compliant. DI does not mean that we need to use interfaces unlike what I had initially thought.
In example below, I am injecting interface variables in place of concrete class instances. This is also a valid example of DI.
public class Invoice
{
public int invoiceId {get;set;}
public DateTime InvoiceDate {get;set;}
public ISupplier SuppliedBy {get;set;}//we are using an interface and not the concrete class
public ICustomer BilledTo {get;set;}//we are using an interface and not the concrete class
public List<ILineItem> LineItems {get;set;}//we are using an interface and not the concrete class
//EMPTY CONSTRUCTOR
public Invoice () {}
//DEPENDENCY INJECTION using constructor
public Invoice(ICustomer cust, ISupplier sup, List<ILineItem> items)
{
this.Customer = cust;
this.Supplier = sup;
this.LineItems = items;
}
}
Yes it is an example of Constructor dependency injection. The dependencies (Customer and Supplier) are injected into the Invoice class through its constructor. See Constructor injection here: http://en.wikipedia.org/wiki/Dependency_injection
Dependency injection is not reliant on interfaces at all. However, you normally see interfaces used to represent a type if the type being injected needs to be interchangeable. That's not normally the case for entities like Customer or Order, but it is more
commonly required for components or services such as a repository or a mailing component.
I think my confusion comes from so many concepts being tied to dependency injection. Before posting my question, I read the following 'confusing' concepts.
Inversion of Control(does not need to use abstractions/interfaces)
Dependency Inversion of Control (should use abstractions/interfaces)
Dependency Injection (does not need to use abstractions/interfaces)
Dependency injection is pattern. It's a specific implementation of the Inversion of control pattern. There are
other forms of implementing inversion of control like the Service Locator pattern,
Strategy Pattern,
Factory Pattern etc. Inversion of control is all about maintaining loose coupling within a system. The main thing is to understand why you should strive for loose coupling in the first place, and then explore the various options you have available to manage
it.
Now its making some sense. But I think implementing these fancy design patterns can be very distracting and time-consuming/wasteful, and I am not sure if they are really needed when trying to deliver software in a 'lean' manner. Today we want to write
software so it satisfies some requirements but in a manner that is not wasteful. Design patterns may introduce waste into the development life-cycle by adding to development time. But this may not always be true, its just my initial impression.
Dependency Inversion of Control ( comes from D in SOLID principles of good software architecture) says we must use interfaces for dependent objects.
Inversion of Control is just a design approach that says do not instantiate dependent objects inside your class, but pass it to your code through a constructor, method or property.
Dependency Injection is one way to implement Inversion of Control design,
Member
377 Points
1257 Posts
Is this code an example of Dependency Injection?
Nov 02, 2014 09:54 AM|sun21170|LINK
public class Invoice { public int invoiceId {get;set;} public DateTime InvoiceDate {get;set;} public Supplier SuppliedBy {get;set;} public Customer BilledTo {get;set;} public List<LineItem> LineItems {get;set;}
//EMPTY CONSTRUCTOR
public Invoice () {}
//DEPENDENCY INJECTION????
public Invoice(Customer cust, Supplier sup, List<LineItem> items)
{
this.Customer = cust;
this.Supplier = sup;
this.LineItems = items;
} }
In above code, Supplier, Customer and LineItem are separate classes. It appears that instances of these classes are being injected through properties into an instance of the Invoice class. We could have also passed these instances to the constructor of Invoice class using the second constructor and still have dependency injection.
My question: Is above code an example of DI (Dependecy Injection) in C#?
All-Star
45489 Points
7008 Posts
Microsoft
Re: Is this code an example of Dependency Injection?
Nov 03, 2014 03:37 AM|Zhi Lv - MSFT|LINK
Hi sun21170,
From my point of view, I don't think it is. Here are some articles about Dependency Injection, you could refer to them.
http://msdn.microsoft.com/en-us/library/ff921152.aspx
http://msdn.microsoft.com/en-us/magazine/cc163739.aspx
http://msdn.microsoft.com/en-us/library/dn178469(v=pandp.30).aspx
Best Regards,
Dillion
Member
377 Points
1257 Posts
Re: Is this code an example of Dependency Injection?
Nov 03, 2014 10:24 AM|sun21170|LINK
Could you explain why the code mentioned is not an example of dependency injection?
We are not instantiating objects within the Invoice object but passing it these objects from outside, so it sounds like DI.
Member
377 Points
1257 Posts
Re: Is this code an example of Dependency Injection?
Nov 06, 2014 01:09 PM|sun21170|LINK
UPDATE: After Mike's answer, I am posting this update. The code snippet in this post, with or without interfaces is DI compliant. DI does not mean that we need to use interfaces unlike what I had initially thought.
In example below, I am injecting interface variables in place of concrete class instances. This is also a valid example of DI.
public class Invoice { public int invoiceId {get;set;} public DateTime InvoiceDate {get;set;} public ISupplier SuppliedBy {get;set;}//we are using an interface and not the concrete class public ICustomer BilledTo {get;set;}//we are using an interface and not the concrete class public List<ILineItem> LineItems {get;set;}//we are using an interface and not the concrete class //EMPTY CONSTRUCTOR public Invoice () {} //DEPENDENCY INJECTION using constructor public Invoice(ICustomer cust, ISupplier sup, List<ILineItem> items) { this.Customer = cust; this.Supplier = sup; this.LineItems = items; } }DEPENDENCYINJECTION
All-Star
193991 Points
28021 Posts
Moderator
Re: Is this code an example of Dependency Injection?
Nov 07, 2014 08:57 AM|Mikesdotnetting|LINK
Yes it is an example of Constructor dependency injection. The dependencies (Customer and Supplier) are injected into the Invoice class through its constructor. See Constructor injection here: http://en.wikipedia.org/wiki/Dependency_injection
Dependency injection is not reliant on interfaces at all. However, you normally see interfaces used to represent a type if the type being injected needs to be interchangeable. That's not normally the case for entities like Customer or Order, but it is more commonly required for components or services such as a repository or a mailing component.
Member
377 Points
1257 Posts
Re: Is this code an example of Dependency Injection?
Nov 07, 2014 10:59 AM|sun21170|LINK
I think my confusion comes from so many concepts being tied to dependency injection. Before posting my question, I read the following 'confusing' concepts.
All-Star
193991 Points
28021 Posts
Moderator
Re: Is this code an example of Dependency Injection?
Nov 07, 2014 11:30 AM|Mikesdotnetting|LINK
Dependency injection is pattern. It's a specific implementation of the Inversion of control pattern. There are other forms of implementing inversion of control like the Service Locator pattern, Strategy Pattern, Factory Pattern etc. Inversion of control is all about maintaining loose coupling within a system. The main thing is to understand why you should strive for loose coupling in the first place, and then explore the various options you have available to manage it.
Member
377 Points
1257 Posts
Re: Is this code an example of Dependency Injection?
Nov 07, 2014 11:58 AM|sun21170|LINK
Now its making some sense. But I think implementing these fancy design patterns can be very distracting and time-consuming/wasteful, and I am not sure if they are really needed when trying to deliver software in a 'lean' manner. Today we want to write software so it satisfies some requirements but in a manner that is not wasteful. Design patterns may introduce waste into the development life-cycle by adding to development time. But this may not always be true, its just my initial impression.
Dependency Inversion of Control ( comes from D in SOLID principles of good software architecture) says we must use interfaces for dependent objects.
Inversion of Control is just a design approach that says do not instantiate dependent objects inside your class, but pass it to your code through a constructor, method or property.
Dependency Injection is one way to implement Inversion of Control design,