Click here to Skip to main content
13,150,867 members (40,302 online)
Click here to Skip to main content
Add your own
alternative version

Stats

9.5K views
170 downloads
18 bookmarked
Posted 19 Apr 2017

Application Architecture - First Know Dependency Before Dependency Injection

, 23 Apr 2017
Rate this:
Please Sign up or sign in to vote.
This article is about dependency, type of Dependency, its use, advantages and disadvantages; as well as it will cover Dependency Inversion, Inverse of Control, and IOC Framework.

Dependency Injection

Audience of the Software Design Topics - Developers, Application Architect.

What will you learn from the topics

I know you already familiar with Dependency Inversion(DI) and Inversion of Control (IOC). So, if you already know this, but you are not confident enough to inject dependency into your components; but you want to reuse your componets and want to know best design practice for  the components then this article is for you. If you prefer Layers style, N-Tier architecture style, Onion or Daisy architecture style using and Domain-Driven-Design or some others then you may need different implementations of the same type of the components for the same or different applications. So,  first know about the dependency, their types and characteristics then injecting the dependency will be very easy and you will be ready to use Dependency-Inversion principle. 

Anyway, the following concepts will be covered in this topic - 

  • What is Dependency
  • Type of Dependency
  • Characteristics of the Dependency
  • Use of the dependency in your class design
  • Dependency Inversion
  • In what Scenarios force to use DI
  • What is DI and IOC
  • Type of DI
  • Advantages and disadvantages of DI
  • IOC Framework
  • Use of Munq to your Web application
  • Use of Managed Extensibility Framework (MEF)

Let's Drilldown the Basic Concept

In DI what's dependency?

No more theory and definition, let's see the example 

In the example,

  • Customer Class needs 'CheckingAccount' and 'SavingAccount' classes to do its work.
  • Customer Class can't do its work without classes 'CheckingAccount' and 'SavingAccount'.

Therefore,

  • Customer Class is a dependent of classes 'CheckingAccount' and 'SavingAccount'.
  • Classes 'CheckingAccount' and 'SavingAccount' are dependency of class Customer

Class Relations of Dependency

  • Two classes (Customer and SavingAccount or CheckingAccount) that use each other are called "coupled".
  • The coupling between classes can be loose or tight or somewhere in between.

Tight Coupling Dependencies

In the example CheckingAccount and SavingingAccount are tightly couple with the customer class. This implementation violates the Opened-Closed principles where your classes should be open for extension but closed for modifications. Anyway, forget the principle. Just think that your checking-account class is fixed in this design and if you need another implantation of the checking-account class then what should you do?

Loose Coupling Dependencies

In the example the implementation of the interface IBankAccount are CheckingAccount and SavingingAccount which are loosely coupled in the customer class. You can inject any different implementation of the IBankAccount into the Customer class.

Direction of Dependency

  • Dependencies or couplings are directional.
  • The Customer depends on CheckingAccount and SavingingAccount , which doesn't mean that CheckingAccount and SavingingAccount also depend on Customer.

Characteristics of Dependency

  • Visible Dependencies
  • Hidden Dependencies
  • Direct Dependencies
  • Indirect Dependencies
  • Compile-Time Dependencies
  • Run-Time Dependency

Visible Dependencies

In the example the implementation of the interface IBankAccount are CheckingAccount and SavingingAccount. If you want to create an instance of a customer class then you can inject any different implementation of the IBankAccount using its constructor. It is visible during object creation.

Hidden Dependency

Now if you create an object of the Customer class then you will not get any chance to inject any of the implementation of the IBankAccount Interface. It is hidden during object creation.

Direct Dependency

In this example, Customer class uses CheckingAccount and SavingAccount. It means Customer has a direct dependency on CheckingAccount' and SavingAccount. So, it is called direct dependency.

Indirect Dependency

In the example CheckingAccount Class has a direct dependency with DataAccessForChecking.

So, Customer has a direct dependency with CheckingAccount. Again Checking Account has a direct dependency with DataAccessForChecking. So, Customer class has an indirect dependency with DataAccessForChecking.

To keep it simple, right now I'm avoiding the compile-Time and run-time dependency. Later I will explain when I will discuss MEF and MUNQ.

Finally I can say that change the way you think then you will realize the fact.

Dependency Inversion

Look at the above example where we are considering a layer architecture. I am taking this architecture as an example. Note that Tier and Layer are two different style. I am ignoring that part as my main goal to show you the DI and IOC.

The Presentation Layer(PL) which may contain User Interface Layer(UI) and Presentation Logic Layer(PLL).To make it easy say we have a web application and the UI means the web-form like *.aspx for ASP.NET or the view like *.cshtml for ASP.NET MVC. PLL means the controller class for the ASP.NET MVC or the *.aspx.cs for ASP.NET.

Business Layer (BL) could be you domain layer. The Data Access Layer (DAL). You can use any ORM like Entity-Frame-work as a DAL.

Say, you have bought some products using any web portal. Now you want to see your order items. So, when you click on a button to display your order then View will communicate with the controller class. Controller class will call the BL and then BL will call the DAL to verify the customer account information and then finally DAL will send the order information to the BL and BL send it to the PL to display the order list.

In a short, the layers work as follows -

  1. PL depends on BL
  2. BL depends on DAL

So, high level layer depends on the low level layers and these are tight coupling layers. We can't change this dependency at the run time or if we have more than one implementations of the DAL or BLL then what happen? Can we able to change the way of the dependency from the layers?

Real Life Scenario

Just for easy understanding let's say, you have different implementation of the DLL. For example, IDataAccess has two implementations and these are DataAccessForSql and DataAccessForOracle. Depending on the customers sometimes you need DataAccessForSql and sometimes you need DataAccessForOracle. But tight coupling design will not help you in this scenarios.

Again you have more than one payment system like PayPal, Visa and MasterCard. You need different implementation of your business logics depending on the payment system. For example, say, IPayment has some implementation like PaymentForMasterCard, PaymentForPayPal and PaymentForVisa. So, you need to switch from one to another depend on the preference of the customer. Tight coupling design will not give you this facilities.

So, solution is the Dependency Inversion.

Principle of the Dependency Inversion

It states that "High-level layers should not depend on low-level layers. Both should depend on abstractions".

So, we can inject any of the implementation of the DAL to the BL and any of the implementation of BL to the PL.

Dependency Injection

Dependency injection is a style of object configuration in which objects are configured by an external entity.

In what Scenarios do you Need DI

  • Never use DI unless - you don't have the control over the lifecycle of the objects.
  • Don't use Container unless something forces you to do that.
  • If you have control to call new to create an object then never need DI container.

Type of Dependency Injection

  1. Constructor Injection
  2. Setter Injection
  3. Interface injection
  • Constructor Injection: Constructor injection uses parameter to inject dependencies.

  • Setter Injection: Use setter method to inject the object's dependencies.

  • Interface injection: Interface injection is used when an object is defined by an interface and it must be implemented in order to inject dependencies at runtime. So, design an interface to inject dependencies

Disadvantage of DI

  • The guessing that you have decoupled by implementing DI without decoupling it. This is the worse part about DI.

Advantage of DI

  • Unit Test or testable code
  • Reuseable code
  • DI helps you with Single Responsibility Principle and Separation of Concerns.

DI is not effective if

You will never need a

  • Different implementation.
  • Different configuration.

Dependency Injection is effective if

You need to inject -

  • Different implementations of the same dependency.
  • The same dependency into multiple components.
  • Configuration data into multiple components.
  • The same implementation in different configurations.

Inversion of Control (IoC)

IoC refers to the containers. It is an implementation of using DI which refers to the actual pattern. IoC containers are useful with static dependencies which is used at compile-time and MEF is useful with dynamic dependencies which is used only at run-time.

List of .NET IOC Framework

  • Unity
  • Managed Extensibility Framework(MEF)
  • Munq
  • Funq
  • LightCore
  • Spring .NET
  • Castle Windsor
  • Autofac
  • Structure Map
  • Puzzle.NFactory
  • Ninject
  • S2Container.NET
  • Winter4Net

Which Dependency Injection Tool Should We Use

  • Munq is good for web
  • Unity is good for Enterprise
  • IOC container is best if you want to implement the entire application.
  • If you want to extend only and it is developed by 3rd-party then MEF could be the best.
  • Ninject is too slow container.

Note that there is some philosophical contradiction. But my main goal to give you an idea; so that, you can capture it easily. This is not hard coded rules; so if you have different opinions then you are right too.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

HR Rony
Engineer GIS
United States United States
Motivated software developer in web/mobile application development, architecture design, and multi-layer implementation. Well-versed in multiple programming languages and platforms. Demonstrated success in UI, integration, and automated unit testing.

You may also be interested in...

Comments and Discussions

 
PraiseThanks Pin
kennedykinyanjui23-Apr-17 22:01
memberkennedykinyanjui23-Apr-17 22:01 
GeneralRe: Thanks Pin
HR Rony24-Apr-17 9:15
memberHR Rony24-Apr-17 9:15 
QuestionDependency Injection Pin
rrotstein21-Apr-17 14:34
memberrrotstein21-Apr-17 14:34 
AnswerRe: Dependency Injection Pin
HR Rony21-Apr-17 16:42
memberHR Rony21-Apr-17 16:42 
GeneralMy vote of 5 Pin
keyur soni19-Apr-17 20:40
memberkeyur soni19-Apr-17 20:40 
GeneralRe: My vote of 5 Pin
HR Rony20-Apr-17 11:32
memberHR Rony20-Apr-17 11:32 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.170924.2 | Last Updated 23 Apr 2017
Article Copyright 2017 by HR Rony
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid