locked
Is this code an example of Dependency Injection? RRS feed

  • Question

  • User1884398186 posted

    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#?

    Sunday, November 2, 2014 9:54 AM

Answers

  • User-821857111 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, November 7, 2014 8:57 AM

All replies

  • User-271186128 posted

    Hi sun21170,


    My question: Is above code an example of DI (Dependecy Injection) in C#?

    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

    Monday, November 3, 2014 3:37 AM
  • User1884398186 posted

    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.

    Monday, November 3, 2014 10:24 AM
  • User1884398186 posted

    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;
        }
    
    }

    Thursday, November 6, 2014 1:09 PM
  • User-821857111 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, November 7, 2014 8:57 AM
  • User1884398186 posted

    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)
    Friday, November 7, 2014 10:59 AM
  • User-821857111 posted

    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.

    Friday, November 7, 2014 11:30 AM
  • User1884398186 posted

    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,

    Friday, November 7, 2014 11:58 AM