Dependency Injection або Don’t call me, I’ll call you

Dependency Injection with Unity 2.0
DmytroMindra
RnD Tech Lead
Lohika
AGILEBASECAMP
Lviv, 2011

Goal
Get DI understanding

Plan
Inversion of Control (IoC)
Dependency Injection pattern (DI)
Dependency inversion principle
Unity 2.0, StructureMap
Guice, Spring
Live ASP.NET MVC Demo

Problem

Problem
We live in an age where writing software to a given set of requirements is no longer enough.
We have to maintain and change existing code.
Code quality ( What’s Bad )R.Martin 1996
Rigid (hard to modify)
Fragile ( errors occur on almost every change)
Immobile (not reusable)

How?
Our solutions should be:
Modular
Testable
Adaptive to change

Terms
Service —An object that performs a well-defined function when called upon
Client —Any consumer of a service; an object that calls upon a service to perform a well-understood function

Terms
Dependency —A specific service that is required by another object to fulfill its function.
Dependent —A client object that needs a dependency (or dependencies) in order to perform its function.

OLD SCHOOL (pre DI STYLE)

Ex1:Composition

Ex1:Composition
public class SpellCheckerService{}
public class TextEditor
{
private SpellCheckerService _spellCheckerService;
public TextEditor()
{
_spellCheckerService = new SpellCheckerService();
}
}
class Program
{
static void Main(string[] args)
{
TextEditor textEditor = new TextEditor();
}
}

What’s good
It’s simple

What’s bad
It’s not testable
It’s hard to maintain/change

Better approach
Dependency Inversion
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.
Robert C. Martin 1996

Context
Context

Ex2:Loose Coupling
public class TextEditor
{
private readonlyISpellCheckerService _spellCheckerService;
public TextEditor(ISpellCheckerServicespellCheckerService)
{
_spellCheckerService = spellCheckerService;
}
public string CheckSpelling()
{
return _spellCheckerService.CheckSpelling();
}
}

Ex2: Unit Testing
// Mock
ISpellCheckerService mock = new SpellCheckerServiceMock();
// Instantiate
TextEditortextEditor = new TextEditor(mock);
// Check
Assert.AreEqual(“Mock”, textEditor.CheckSpelling());

What changed
TextEditor lost its “Sovereignty” and is not able to resolve dependencies by himself.

What’s good
Dependencies are obvious.
Dependency resolution is not encapsulated.
Unit Testing is applicable
Architecture is much better

What’s bad
We are resolving dependencies manually while creating instances of TextEditor.

Wiring By Hand

Using Factory

Factory

What changed
Any required combination of Text Editor and Spell Checking Service is created by object factory.

What’s good
It’s testable
No manual wiring

What’s bad
You have to maintain factory or service locator
The more combinations the more methods we have in factory.
Your code knows about the specific factory or factory interface. This means that infrastructure logic is mixed with business logic.
Factory may have states.

Service Locator
Unfortunately, being a kind of Factory, Service Locators suffer from the same problems
of testability and shared state.

What are we looking for?

Inversion of Control
Hollywood Principle:
Don’t call me, I’ll call you

Inversion of Control
IoC – is a common characteristic of frameworks.
According to Martin Fowler the etymology of the phrase dates back to 1988.

Dependency Injection
DI is a kind of IoC
Inversion of Control is too generic a term
DI pattern – describes the approach used to lookup a dependency.
Dependency resolution is moved to Framework.

We have alreadyprepared basis.
Loosely
coupled
structure

It’s time to introducenew role
Injector
(sometimes referred to as a provider or container)

Depedndecy Injection
DI in general consists of
a dependent consumers
their service dependencies
and an injector

Ex3: Unity
using Microsoft.Practices.Unity;
UnityContainer container = new UnityContainer();
container.RegisterType<ISpellCheckerService, SpellCheckingService>();
TextEditortextEditor = container.Resolve<TextEditor>();

What changed
Unity container now resolves dependencies

What’s good
Automated dependency resolution
Business logic and infrastructure are decoupled.

Injection Types
Interface injection (by Martin Fowler)
Constructor Injection (by Martin Fowler)
Setter injection (by Martin Fowler)
Method call injection (Unity)
Method decorator injection (Guice)

Unity methods
RegisterType
RegisterInstance
Resolve
BuildUp

Ex4: Unity Configuration
<configSections> <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/> </configSections> <unity xmlns="http://schemas.microsoft.com/practices/2010/unity"> <alias alias="ISpellCheckerService" type="Unity.Config.ISpellCheckerService, Unity.Config" /> <alias alias="SpellCheckingService" type="Unity.Config.SpellCheckingService, Unity.Config" /> <namespace name="Unity.Config" /> <assembly name="Unity.Config" /> <container> <register type="ISpellCheckerService" mapTo="SpellCheckingService" /> </container> </unity>

Ex4: Unity Configuration
using Microsoft.Practices.Unity;using Microsoft.Practices.Unity.Configuration;UnityContainer container = new UnityContainer();container.LoadConfiguration();TextEditor textEditor = container.Resolve<TextEditor>();

Dependency tree

Ex5: Dependency tree
public interface IAdditionalDependency{}
public class AdditionalDependency : IAdditionalDependency{}
public class SpellCheckingService: ISpellCheckerService
{ public SpellCheckingService( IAdditionalDependency dependency){}
}

Ex5: Dependency Tree
UnityContainer container = new UnityContainer();container.RegisterType<ISpellCheckerService, SpellCheckingService>();container.RegisterType<IAdditionalDependency,
AdditionalDependency>();TextEditor textEditor = container.Resolve<TextEditor>();

Ex5: Dependency tree

Ex6: Defining Injection Constructor
public class TextEditor { private readonly ISpellCheckerService _spellCheckerService; [InjectionConstructor] public TextEditor(ISpellCheckerService spellCheckerService) { _spellCheckerService = spellCheckerService; } public TextEditor(ISpellCheckerService spellCheckerService,string name) { _spellCheckerService = spellCheckerService; } }

Ex7: Property Injection
public class TextEditor { public ISpellCheckerService SpellCheckerService {get; set;} [Dependency] public ISpellCheckerService YetAnotherSpellcheckerService{get;set;} }
UnityContainer container = new UnityContainer(); container.RegisterType<TextEditor>(new InjectionProperty("SpellCheckerService")); container.RegisterType<ISpellCheckerService, SpellCheckingService>(); TextEditor textEditor = container.Resolve<TextEditor>();

Ex8: Method call injection
public class TextEditor { public ISpellCheckerService SpellcheckerService {get; set;}
[InjectionMethod] public void Initialize (ISpellCheckerService spellcheckerService) { _spellCheckerService = spellcheckerService; }
}
UnityContainer container = new UnityContainer();//container.RegisterType<TextEditor>(
new InjectionMethod("SpellcheckerService"));container.RegisterType<ISpellCheckerService, SpellCheckingService>();TextEditor textEditor = container.Resolve<TextEditor>();

Lifetime Managers
TransientLifetimeManagerReturns a new instance of the requested type for each call. (default behavior)
ContainerControlledLifetimeManagerImplements a singleton behavior for objects. The object is disposed of when you dispose of the container.

Lifetime Managers
ExternallyControlledLifetimeManagerImplements a singleton behavior but the container doesn't hold a reference to object which will be disposed of when out of scope.
HierarchicalifetimeManagerImplements a singleton behavior for objects. However, child containers don't share instances with parents.

Lifetime Managers
PerResolveLifetimeManagerImplements a behavior similar to the transient lifetime manager except that instances are reused across build-ups of the object graph.
PerThreadLifetimeManagerImplements a singleton behavior for objects but limited to the current thread.

Ex9: Unity Singleton
UnityContainer container = new UnityContainer();container.RegisterType<ISpellCheckerService, SpellCheckingService>(new ContainerControlledLifetimeManager());TextEditor textEditor = container.Resolve<TextEditor>();

Container Hierarchy

Unity Limitations
When your objects and classes have no dependencies on other objects or classes.
When your dependencies are very simple and do not require abstraction.

Performance

What DI stands for
For
Wiring framework components
Not for
Wiring small parts

Structure MAP

Structure Map Example
// Bootstrap
Container container = new Container(x => x.For<ISpellCheckingService>(). Use<FrenchSpellCheckingService>());// Use
TextEditor textEditor = container.GetInstance<TextEditor>();

Compared to Unity
// Bootstrap
UnityContainer container = new UnityContainer();container.RegisterType<ISpellCheckingService,
EnglishSpellCheckingService>();// Using containerTextEditor textEditor = container.Resolve<TextEditor>();

Unity vsStructureMap
Unity
XML Configuration
In Code configuration
Attributes
Benefits
Easy code initialization
Good documentation
StructureMap
XML Configuration
In Code configuration
Attributes
Benefits
Http & Session lifetime managers out of the box.
Convenient XML configuration.

.NET DI Frameworks
Unity 2.0
AutoFac 2.4.3
StructureMap 2.6.1
Castle Windsor 2.5.3
Ninject 2.0

SCOPE, Context, Lifetime

Singleton scope
Singleton scoped objects lifetime is bound to injector lifetime.

Difference
Singleton scoped object vs. singleton anti pattern

No scope

Connection pool

Web request scope
HTTP protocol is stateless and web request scope is quite natural for web applications

Session scope
Session is an abstraction that hides HTTP stateless nature. Such scope should be used carefully.

Circular References

Circular References
Objects depend on each other forming cycle in dependency graph.

General case
A depends on B
B depends on A

Introducing proxy

Diagram
Dynamic proxy is constructed

Sequence
1. Instantiate Proxy A
2. Instantiate B using Proxy A
3. Instantiate A using B from step 2
4. Initialize Proxy A with A
Proxy A passes all requests to concrete A

Granny and APPLES
REINJECTION

G&A Diagram
Granny receives concrete apple via injection.
Granny eats apple

G&A Sequence
Granny needs apples for proper operation
New apples should be injected runtime

G&A Solution
Instead of single apple we should inject apple “provider”

G&A New Sequence

Drawback
If you want produced instances to be configured by general injection rules then your factories will depend on concrete injection framework.
Google Guice has special interface to support such behavior but you’ll depend on googleGuice.
No silver bullet.

GUICE AND Spring

History
Spring project brought DI to mainstream.
And thank Spring Guice appeared.
Guice introduced new features and stimulated further Spring development.
Now Guice and Spring are almost equal in DI field and which one to use depends on developer.

Spring
Spring holds a huge DI market share. More than 80%.
Proven enterprise solution
DI is only a small part of its functionality
Supports all major injection approaches
Current version 3

Guice
New kid on the block
Introduced new features based on Java 5 support. ( e.g. Provider methods to circumvent type erasure)
First-class error messaging.
Very fast.
Provides only DI
Current version 2 ( Version 3 RC )

Spring or Guice
In DI Spring and Guice are almost equal.
Guice provides only DI
DI in Spring is only a part of functionality
Google extensively uses Guice
Guice is trendy and developers just want to give it a try.
So which framework to use heavily depends on project and concrete developer ( team)

Where to use Guice
If you are sure that you do not need full Spring functionality and your project is not a huge enterprise level application then you can give it a try.
Spring is standard de facto in the industry.

Patterns
Builder
Wrapper
Adapter
Abstract Factory and Factory method

Additional reading

Live Demo

ASP.NET MVC

Questions ?

Thank YOU !

References
1. Martin Fowler – Dependency Injection
http://martinfowler.com/articles/injection.html
2. DI Comix
http://www.bonkersworld.net/2010/08/11/programmers-only-shaving-who/
3. Consultants comix
http://stuffthathappens.com/blog/2007/09/26/comic-tribute-to-crazy-bob/
4. R. Martin - Dependency Inversion principle
http://www.objectmentor.com/resources/articles/dip.pdf

http://lviv.agilebasecamp.org	48
http://agilitynature.blogspot.com	21
http://7.hidemyass.com	1

Dependency Injection або Don’t call me, I’ll call you

by Dmytro Mindra on Feb 06, 2011

Accessibility

Tags

Upload Details

Usage Rights

3 Embeds 70

Statistics

Dependency Injection або Don’t call me, I’ll call you — Presentation Transcript