Understanding Dependency Injection… and those pesky containers Miguel A. Castro Architect -

ineta .NET Architect, Developer, & Trainer  Microsoft MVP  ASP Insider  VSX Insider  C# Insider  Azure Insider  Member of the INETA Speakers Bureau  Conference Speaker  In IT business since 1986

Have you seen this woman?

Agenda Classes, Dependencies, and Coupling DI Explained & Demoed DI Containers A Tour Through Several Containers –Unity, –NInject, –Castle Windsor –StructureMap –MEF

Agenda Dependency Injection usage –WPF / Silverlight / WinRT –ASP.NET MVC –ASP.NET WebForms (yes, you read right)

Class coupling (why it’s bad) One class depending on another –Cannot exist (compile) without other class Limits functionality to single implementation If classes perform DB work, difficult to test without hitting DB

To decouple, abstract Program to interfaces (or abstract classes) Hosting class uses interfaces –Can receive any implementation –Can have real one for production –Mocked one for testing

DEMO Esentials (coupled and abstracted)

What is Dependency Injection An architectural pattern designed to easily satisfy a class’ dependencies –Allows us to write decoupled code –Facilitate testability –Ease deployment of components Typically implemented with the aid of an object container

The DI Container A repository for definitions typically relating an abstraction to a concrete class Core functionality –Provide facility for registering classes Usually related to interfaces –Provide facility for resolving a request Usually from a given interface (not always)

The DI Container Type associations (registrations) achieved depending on container –Procedural (fluent interface) Unity, NInject, Castle Windsor, StructureMap –Configuration Spring.NET –Declarative (attributes) Managed Extensibility Framework (MEF)

The DI Container Recursively resolves dependencies Injected interface variables –Constructor (usual) –Property Requesting one class (from container) starts chain reaction

DEMO DI Container internals Poor-Man’s DI Container

Unity Microsoft’s contribution to DI Containers Code-based registration XML-based registration Constructor injection Provides interception (aspects) Part of Enterprise Library

NInject Code-based registration Attribute-based registration Constructor injection

Castle Windsor Second oldest DI container for.NET XML-based registration Code-based registration One of the more popular DI containers

StructureMap Oldest DI Container for.NET Code-based registration XML-based registration Attribute-based registration

Spring.NET Port from Spring for Java XML-based registration (originally) Code-based registration Provides many additional features –AOP being a key one Lots of “business framework” functionality

MEF Not a true DI container (so they tell me) –Serves purpose well though Framework for providing add-in architecture to application Provides features not found in DI containers

MEF Uses discovery mechanism to find components (good) –Only interfaces known at compile-time Components coupled to discovery mechanism (bad) –Attribute driven For most DI needs, works nicely –All, in my case

MEF Discovery mechanism allows extra customization –Can extend Export and Import attributes and alter discovery behavior Include with.NET Framework

DEMO DI Containers

Container Comparison ContainerRegistrationInjectionMultiple Constructors UnityProgrammatic, XML Constructor, Limited Property Yes NInjectProgrammaticConstructor, Limited Property Yes Castle WindsorProgrammatic, XML Constructor, Property Yes StructureMapProgrammatic, XML, Discovery Constructor, Limited Property Yes Spring.NETProgrammatic, XML Constructor, Property Yes MEFDiscoveryConstructor, Property No

DI in WPF / Silverlight / WinRT Used to resolve ViewModel classes –Used to resolve dependencies injected into ViewModels –Used to resolve nested ViewModels ViewModels can be tested and test dependency implementations used

DI in ASP.NET MVC Used to resolve controller classes –Used to resolve injected dependencies into controllers Can use a custom controller factory MVC offers dependency resolver Controllers can be tested and test dependency implementations used

DI in ASP.NET WebForms Used to resolve injected dependencies into requested web forms Uses a custom page handler factory Testing code-behind classes still troublesome

DEMO DI Container Usage

Conclusion DI Containers assist in managing components to be used The core principle is usage of interfaces to build decoupled components Containers offer different features –For most part, all accomplish the same thing MEF is first class citizen

References Dependency Injection in.NET –Mark Seemann – Manning Martin Fowler’s DI/IoC article – Tons of info on the web

Miguel A. Castro Thank You