Dependency Injection

Amareswara Rao
 Software Design
Patterns

A software design pattern is used to formalize

the description of a problem and a solution to
that problem, so that developers can use the
pattern to simplify the identification and
communication of common problems and
solutions.
 Design Pattern:
Inversion of Control
You can see that NotificationSystem has a
dependency on EmailService . When a component
has a dependency on something else, we call that
coupling

A class that knows a lot about the other classes it

interacts with (as in the preceding example) is said to
be tightly coupled.

In software design, tight coupling is often considered

to be a liability in your design.

When one class knows explicitly about the design and

implementation of another class, you raise the risk
that changes to one class will break the other class.
 Reduce coupling
Introduce an abstraction layer
between two pieces of code.

To perform this step in .NET,

you often use interfaces (or
abstract classes) to represent the
abstractions between two
classes.

Move the responsibility of

choosing the implementation of
the abstraction to outside of the
consuming class.
 IoC
Moving the creation of dependencies outside of the class
that consumes those dependencies is called the inversion
of control pattern, so named because what you're
inverting here is the creation of dependencies (and in so
doing, you are removing the control of dependency
creation from the consumer of the class).

The inversion of control (IoC) pattern is abstract;

Design Pattern: Service Locator

Design Pattern: Dependency Injection.

Design Pattern: Service
Locator
The service locator pattern says that inversion of control
is achieved by having components get their dependencies
through an external component known as the service
locator.

Strongly Typed Service Locator

A strongly typed service locator for the sample

application might have an interface like this:
Why might you not choose a strongly typed service locator?

First, this service locator is limited to creating objects of types that have
been predetermined at the time that IServiceLocator was designed. It's
not capable of creating any other types.

Second, it could become a maintenance burden having to constantly

expand the definition of IServiceLocator as you find need for more
services in your application.
Weakly Typed Service Locator

This variant of the service locator pattern is much

more flexible, because it allows you to ask for any
arbitrary service type. It's called a weakly typed
service locator because it takes a Type and returns
an un-typed instance (that is, an object of type
Object ). You need to cast the result of the call to
GetService to get the correctly typed object back.
This code is a little less pretty than the previous
version, owing primarily to the required casting
to IMessagingService . With the introduction of
generics in .NET 2.0, you could have also
included a generic version of the GetService
method:
 The Pros and Cons of
Service Locators
It creates opacity of requirements for your
component: The developers who consume your
component can't tell just by looking at the
constructor signature what your service
requirements are going to be. They are forced to
consult documentation, which may be out of
date, or simply to pass in an empty service
locator and see what kinds of things you request.
 Design Pattern:
Dependency Injection
The dependency injection (DI) pattern is another
form of the inversion of control pattern,

there is no intermediary object like the service

locator. Instead, components are written in a
way that allows their dependencies to be stated
explicitly, usually by way of constructor
parameters or property setters.
Constructor Injection
This technique involves creating a constructor
for your class that expresses all of its
dependencies explicitly
 Property Injection
This code removes the constructor arguments (in fact, it
removes the constructor entirely) and replaces it with a
property. This class expects any consumers to provide you with
your dependencies via properties rather than the constructor.
If your dependencies are truly optional in the
sense that you have some fallback when the
consumer doesn't provide you with one,
property injection is probably a good choice.

Instances of your class might be created in such

a way that you don't have control over the
constructor that's being called. This is a less
obvious reason. You'll see a couple of examples
of this later in the chapter when we discuss how
dependency injection is applied to view pages.
Dependency Injection
Containers

dependency injection container is one way to

make the resolution of these dependencies
simpler.

The difference is in the details,

You tell the service locator, If anybody asks for this
type, you give them this object.

A dependency injection container, on the other hand, is

often configured with logic like, If anybody asks for this
type, you create an object of this concrete type and give
them that.

The implication is that creating the object of that concrete

type will, in turn, often require the creation of other
types to fulfill its dependency requirements. This
difference, while subtle, makes a fairly large difference in
the actual usage of service locators versus dependency
injection containers.
Dependency Resolution
in MVC

The primary way that MVC talks to containers is through an

interface created for MVC applications: IDependencyResolver .

If you want to register a dependency injection container (or a

service locator, for that matter), you need to provide an
implementation of this interface. You can typically register an
instance of the resolver inside your Global.asax file.

DependencyResolver.Current = new MyDependencyResolver();