I gotta dependency on dependency injection

transcript

I Gotta Dependence on

Dependency Injection

November 15 2014

Matt Henroid (@mhenroid)

Senior Consultant

Daugherty Business Solutions

Agenda

• SOLID Principles

• Coupling

• Refactoring Dependencies to Abstractions

• Inversion of Control

• Dependency Injection (DI)

– Constructor Injection

– Property / setter injection

– Method injection

– Ambient Context

• Automated Testing

• Object Composition / Lifetime Management

• DI Frameworks

• S – Single responsibility

– A class should have only a single responsibility

• O – Open / closed principle

– Classes should be open for extension, but closed for modification

• L – Liskov substitution principle

– Objects of a program should be replaceable with instances of their subtypes

• I – Interface segregation principle

– Many client-specific interfaces are better than one general-purpose interface

• D – Dependency inversion principle

– One should depend on abstractions and not concretions

– Not the same as Dependency Injection but related

The 5 commandments of OO design

ObjectA

InterfaceB InterfaceC

Method1() Method2()

ObjectB ObjectC

Method1() Method2()

Loose Coupling

ObjectA

ObjectB ObjectC

Method1() Method2()

Tight Coupling

Tight vs. Loose Coupling

• Coupling

– Degree to which one component (i.e. dependency) has knowledge of another

• Tight Coupling

– A class has a direct reference to a concrete class.

• Loose Coupling

– A class has a reference to an abstraction which can be implemented by one or more

classes.

ObjectA

InterfaceB InterfaceC

Method1() Method2()

ObjectD ObjectE

Method1() Method2()

Loose Coupling

ObjectA

ObjectD ObjectE

Method1() Method2()

Tight Coupling

Tight vs. Loose Coupling

• Benefits of Loose Coupling

– Testability – easier to test objects in isolation

– Reuse – dependencies can be swapped without modifying target

– Open / Closed Principle - change behavior without modifying target

– Parallel development – developers can work in parallel more easily

Tight Coupling Example

Violating Single Responsibility

Tight Coupling Example

How do we test WidgetDataProvider in isolation

from its dependencies?

How can we reuse or change WidgetDataProvider?

Refactoring Dependencies to Abstractions

• Interfaces

– Every declared method must be implemented by concrete class

• Abstract classes

– Only methods declared abstract must be implemented by concrete class

– Can provide some default implementation for methods not declared abstract

• Extract interfaces from classes

Before After

• Replace static classes / methods with non-static

Before After

• Extract non-deterministic dependencies

– Timers, Threading, DateTime dependent

Before After

• Extract non-deterministic dependencies

– Timers, Threading, DateTime dependent

• Replace concretions with abstractions

Before After

Abstraction Example

Inversion of Control (IoC)

• Traditional programming

– Dependencies are instantiated by a class that need them

• Inversion of Control (IoC)

– Dependencies are instantiated by a 3rd party and supplied to a class as needed

DependencyA DependencyB

ChildClass

IDependencyA IDependencyB

ChildClass

creates/consumes creates/consumes

ParentClass

creates/consumes

ParentClass

createsconsumes

Traditional Inversion of Control

consumesconsumes

RootContext

consumes

SomeClass creates

SomeClass

creates

SomeClass

creates

SomeClass creates

RootContext

creates/consumes

Inversion of Control (IoC)

• Dependency Injection

– Constructor Injection

– Property / Setter Injection

– Method Injection

– Ambient Context

• Factory pattern

– Dependencies created by factory class

– Factories can be injected via DI

• Service locator

– Class uses Service Locator to pull dependencies as needed

– Anti-pattern

• Hides a class’ dependencies

• Dependencies magically appear

• Great way to introduce runtime exceptions

– Caution

• Avoid using DI frameworks as Service Locator

Implementations

Constructor Injection

Use readonly fields as backing store

Inject dependencies via constructor

Guard against null arguments

Save dependencies to field

• When to use

– When a dependency is required

• Important considerations

– Use single constructor

– Keep constructors lightweight

– Minimize number of dependencies (1-3)

Property / Setter Injection

Use public get/set to inject dependencies.

Guard against null references (if necessary)

• When to use

– When a dependency is optional or changeable at runtime

– When default constructor is required (ASP.NET Pages/Controls)

Method Injection

Dependencies passed as parameters on every call

Guard against null arguments

• When to use

– When a method requires different dependency for each call

Ambient Context

Set a default. If no default then use NullObject pattern

Static get/set allows access to current logger

Guard against null values

Implement concrete logger

Extract static methods to an interface

• When to use

– Cross cutting concerns (i.e. Logging, Security, etc.)

– Avoid polluting constructors with global dependencies

• Important considerations

– Thread safety

– Use sparingly

Automated Testing

• Unit Testing

– Test a class in isolation from dependencies

– Use mock objects in place of dependencies

• Roll your own

• Framework (i.e. Moq)

– Unit tests should never interact with a database

– Should be extremely fast

• Integration Testing

– Test a class along with its dependencies

– More complex than unit tests

– May include database calls which can be slow and brittle

TestInitialize

Create fields for our mocks and target for testing

Create mocks and inject as needed

Create mocks and inject into target constructor

TestMethod

GetWidgets() successful path

Configure our mocks to return test data.

Use Verifiable() to ensure that these specific methods

were called.

Execute the method we’re testing

Verify the results are as expected

TestMethod

GetWidgets() exception handling

Configure data feed to throw an exception

Ensure exception is logged

Verify the exception is thrown

Object Composition / Lifetime Management

• Object Composition

– How and where do we instantiate and inject dependencies?

• Object Lifetime Management

– How do we manage the lifetime of dependencies?

– How do we manage sharing dependencies?

Object creation

Use the data provider

Objects go out of scope and are garbage collected.

Object Composition

• Single place in application where object graph is created

• Nearest the application entry point

• Examples

– Console App = Main method

– Windows Services = Main method

– ASP.NET Web Forms = global.asax

– ASP.NET MVC = IControllerFactory

– WCF = ServiceHostFactory

Composition Root

WidgetDataProvider

SqlWidgetDataFeed WidgetDataReader

Simple Object Graph

Composition Root

WidgetDataProvider

SqlWidgetDataFeed WidgetDataReader

More Realistic Object Graph

Composition Root

Dependency Injection Frameworks

• How they make life easier

– Automatically detect and resolve dependencies (Autowiring)

– Manage object lifetime and sharing between objects (Lifetime Management)

– Allow disposing of all registered dependencies

• Lifecycle

– Register

• Perform early in application (application composition root)

• Perform all registrations at the same time

– Resolve

• Typically only resolve at the composition root

• Resolving elsewhere = Service Locator anti-pattern

– Dispose

• Dispose of DI container to ensure registered objects are disposed

• Examples

– Unity (Microsoft), Ninject, Castle Windsor, Autofac, StructureMap, …

UnityExample

Create DI container

Register dependencies

Resolve root component

DI container and all components disposed

Registration

• Code

– Simplest but requires recompiling when changes made

Registration

• Code

• XML

– More difficult (no editor) but no recompiling when changes made

Registration

• Code

• XML

– More difficult (no editor) but no recompiling when changes made

• Convention

– Good for large applications

• Transient (default)

– New instance created for each call to Resolve

• Container Controlled (i.e. singleton)

– Shared instance when Resolve or dependency injected

• Externally Controlled

– Similar to Container Controlled (i.e. singleton)

– Weak reference kept so container does not handle disposing

• Per Thread

– One instance created per thread

Lifetime Managers

Resolving

Dependency Injection Frameworks

Unity (3.0) Ninject Castle Windsor Autofac StructureMap

License MS-PL Apache 2 Apache 2 MIT Apache 2

Code Configuration Yes Yes Yes Yes Yes

XML Configuration Yes Yes Yes Yes Yes

Auto Configuration Yes Yes Yes Yes Yes

Auto Wiring Yes Yes Yes Yes Yes

Lifetime Managers Yes Yes Yes Yes Yes

Interception Yes Yes Yes Yes Yes

Constructor Injection Yes Yes Yes Yes Yes

Property Injection Yes Yes Yes Yes Yes

Feature Comparison

• Same basic features

• Each has advanced features that set them apart

• Be aware of performance

• Research a few before choosing

References

• Dependency Injection in .NET (Mark Seemann)

– http://techbus.safaribooksonline.com/book/programming/csharp/9781935182504

• Adaptive Code via C# (Gary McLean Hall)

– http://techbus.safaribooksonline.com/9780133979749/

• Intro to Inversion of Control (IoC)

– http://msdn.microsoft.com/en-us/library/ff921087.aspx

• Service Locator is an Anti-pattern (Mark Seemann)

– http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/

• Developer’s Guide to Dependency Injection Using Unity

– http://msdn.microsoft.com/en-us/library/dn223671(v=pandp.30).aspx

• IOC Framework Comparison

– http://blog.ashmind.com/2008/08/19/comparing-net-di-ioc-frameworks-part-1/

– http://www.palmmedia.de/blog/2011/8/30/ioc-container-benchmark-performance-

comparison

I gotta dependency on dependency injection

Software