Dependency Injection on-ramp

What is dependency injection?

- Dependency injection is a software design pattern that allows a choice of component to
made at run-time rather than compile time – Wikipedia - 2012 this means: Late Binding
(run-time binding) is just one benefit of Dependency Injection

- Dependency injection is a software design pattern that allows the removal of hard-coded
dependencies and makes it possible to change them, whether at run-time or compile-time –
Wikipedia, 2013 – this means: A little better: includes both compile-time and run-time
bindings

- Dependency injection is a set of software design principles and patterns that enable us to
develop loosely coupled code – Mark Seemann

Why loosely-coupled code?

- Loose coupling means that our classes, modules, and assemblies have good isolation from
each other
- Extensibility - we get code that's extensible, code that can respond quickly to new
requirements. If we need to swap out an existing feature for one with different
functionality, this becomes very easy to do
- Testability - we also improve the testability of our code. It is technically possible to unit test
almost any piece of code. However, if our code is not designed for testability then we can
end up with some very convoluted unit tests
- Late binding – this is about dynamically loading modules when we run the application. This
allows us to ship different components to different clients and our application picks up the
right functionality when we run it.
- Parallel development - Loose coupling also makes it easy to develop modules in parallel. If
one module does not directly depend on another module, but instead is loosely coupled, we
can have different members of the team working on these modules at the same time and
changes to one module do not directly impact another module
- Maintainability – If we have the different parts of our code isolated from each other, we
know where we need to go to fix bugs or make updates and we do not have to worry about
making the same change over and over again in different parts of the application.

Patterns - There are a number of different patterns that we can use to implement Dependency Injection:
- Constructor Injection – most used patterns
- Property Injection – most used patterns
- Method Injection
- Ambient Context
- Service Locator

1
Object Composition - Another concept of Dependency Injection is how we compose our objects. Our
goal is loose coupling, but we have to be able to snap these loosely coupled pieces of code together to
form our application. In Dependency Injection, we refer to this as the Composition Root.
DI Containers - When we implement Dependency Injection on our application, we most likely will not do
this manually. Instead, we will use one of the many Dependency Injection Containers that are available
to us. These include:
- Unity – from the Microsoft Patterns and Practices Team
- Ninject
- Castle Windsor
- Autofac
- StructureMap
- Spring.NET – which is a .NET port of the Spring framework in the Java world
- And many others

Dependency injection containers – There are a number of dependency injection containers to choose
from. These are sometimes referred as Inversion of Control or IoC containers. Here are some of the
most. The good news is that the most popular ones support the same features. Here are just a few of
the more popular Containers:
- Unity comes from the Microsoft Patterns & Practices Team. It's available as a free download.
- Spring.NET is more than just a DI Container, it's an entire framework with many features.
Dependency Injection is just one of those. Spring.NET is a port of the Spring framework from
the Java world, so this may be a good choice if you have both .NET and Java applications in
your portfolio.
- Castle Windsor comes out of the Castle Project.
- Ninject
- Autofac
- StructureMap
- And many others.

Late binding- Late Binding allows us to make decisions about what objects we want to use at run-time.
We can dynamically load assemblies and use those in our applications.

DI Containers offer us Lifetime Management:

- Singleton - have a single instance that everyone shares
- Transient - have a new instance each time we ask for it
- Per Thread - have a single instance for each thread in our application
DI Containers offer object resolution.
- Automatically Creates Dependencies Required By Constructor Injection - They resolve
objects by looking at Constructors and automatically creating dependent objects
- Configurable for Property Injection Objects - we can configure our Containers to inject
properties
Late Binding

2
- Dynamic Loading through Configuration - we could use XML Configuration to dynamically
load types and assemblies at run-time. This lets us swap out dependencies without needing
to recompile our code.