Application Architecture - First Know Dependency Before Dependency Injection

Dependency Injection

Audience for this topic - Developers and Application Architects.

What will you learn from the topic

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 

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

 

In the example,

• Customer Class needs classes '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 IBankAccount) 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 coupled 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 IBankAccount which doesn't mean that IBankAccount also depends 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 IBankAccount. It means Customer has a direct dependency on IBankAccount. 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 lass 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 Section.

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 SR (Single Responsibility) and SoC (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 You 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 is to give you an idea so that, you can capture it easily. These are not hard coded rules; so if you have different opinions then you are right too.