Dependency Injection and Autofac

Dependency Injection and Autofac

By: Keith Schreiner & Jeff Benson

Goals

1) Provide basic info about DI.2) Get you excited to use DI.3) Get you to recommend using a DI tool (like

Autofac) on your next project.

Why?

DI enables loose coupling, and loose coupling makes code more maintainable.

Great for medium or big applications that need to be maintained.

DI can change the way you write software. (Good)Instead of bottom-up, DI allows for top-down.

(DB to UI) (UI to DB)

Definition of Dependency Injection

• A set of object-oriented software design principles & patterns that enable us to develop loosely coupled code, by passing or setting the dependencies of a program.

• Instead of components having to request dependencies, they are given (injected) into the component.

• (Sounds complex, but really isn’t.)

Explain Dependency Injection to a 5-year old

When you go and get things out of the refrigerator for yourself, you can cause problems.

You might leave the door open, you might get something Mommy or Daddy doesn't want you to have. You might even be looking for something we don't even have, or which has expired.

What you should be doing is stating a need, "I need something to drink with lunch," and then we will make sure you have something when you sit down to eat.

From John Munsch on Stack Overflow

DI is a set of Design Patterns & Principles

Making code more maintainable through loose coupling is the core motivation behind many classic design patterns (dating back to 1995 and the Gang of Four):

Program to an interface, not an implementation

Property Injectionpublic partial class SomeClass{ private ISomeInterface dependency; public ISomeInterface Dependency { get { if (this.dependency == null) this.Dependency = new DefaultSome(); return this.dependency; } set { if (value == null) throw new ArgumentNullException("value"); if (this.dependency != null) throw new InvalidOperationException(); this.dependency = value; } } public string DoSomething(string message) { return this.Dependency.DoStuff(message); }

When a dependency is optional. + Simple to understand. - But limited in its use. - Not simple to implement robustly.

SOLID & DIS Single Responsibility Principle

• An object should have only a single responsibility.

OOpen/Closed Principle• Software entities should be open for extension, but closed for

modification.

LLiskov Substitution Principle• Objects in a program should be replaceable with instances of their

subtypes without altering the correctness of that program.

IInterface Segregation Principle• Many client specific interfaces are better than one general purpose

interface.

DDependency Inversion Principle• One should depend on abstractions; do not depend upon

concretions.

Benefits of DI

• Late Binding• Extensibility• Parallel Development• Maintainability• Testability• Code Structure

– Interface Driven Development– All dependencies registered in one spot– Never have to write code to “new-up” objects.

Negatives of DI

• Learning curve.

• Constructor code may look more complicated.

• Code may seem “magical” for developers who do not know DI.

• Is over-kill for very small projects.

• Makes classes harder to re-use outside of a DI app.

DI Myths

• Not just relevant for late binding.

• Not just relevant for unit testing.

• Is not just a Service Locator.

DI or Inversion of Control

Sometimes DI and IoC are interchanged.

IoC = Inversion of ControlIoC = A framework controls program flow.

IoC includes DI.

Example

A “Hello World” or any small example will do a horrible job of showing off DI. But here it is…

[Shipping with Weather]1. Write some Interfaces2. Implement some classes. Class Foo : IFoo3. Create a class to load the modules4. In this loading-class, register and configure your classes5. In the startup of your program, register this loading-class

DI Dimensions (Ideas)1) Object Composition2) Object Interception3) Object Lifetime Management

a) InstancePerDependency

b) SingleInstance

c) InstancePerLifetimeScoped) InstancePerMatchingLifetimeScope

.NET DI Containers

There are many good choices (feel free to try others):• Castle Windsor (Popular, but big. Good choice)• Structure Map (Oldest [2004] .net DI container, popular)• Spring.NET (port from Java, big learning curve)• Unity (From Microsoft’s P&P team, solid but different)• Ninject (Good, simple to use)• Autofac (Most recent, based on C# 3, gaining popularity)

Plus about 10 other not-as-popular ones.

Autofac

• Get it: http://autofac.org or NuGet.

• What you get: a zip with binaries.

• Platforms: .NET 3.5 SP1, .NET 4, Silverlight 3 & 4, Windows Phone 7.

• Cost? Free. It is open source.

• Help? http://autofac.org or StackOverflow

• ReSharper also really helps speed-up dev.

Autofac Integration

Autofac has additional packages for integration:• ASP.NET WebForms• ASP.NET MVC3• WCF (Windows Communication Foundation)• And others

Using Autofac

1) Develop your code using DI-friendly patterns2) Configure Autofac

1) Create a ContainerBuilder2) Add configuration.

• Tell the ContainerBuilder your objects, and interfaces, and lifetimes, etc.

3) Create a Container (from the ContainerBuilder)4) Use the Container to resolve components (objects).

Configuration

• Code• Auto (using an assembly)• XML

Recommend: Use Package config Autofac.Module

Registering Dependencies in Autofac

1) Type, lambda expression, specific instance, or auto-registerbuilder.RegisterType<TaskController>();

builder.Register(c => new TaskController(c.Resolve<ITaskRepository>())

);

builder.RegisterInstance(new TaskController());

builder.RegisterAssemblyTypes(typeof(IPresenter).Assembly) .Where(t => t.IsAssignableTo<IPresenter>()) .OnActivating(e => ((IPresenter)e.Instance).SetupView());

Lifetime Options

1. InstancePerDependency2. InstancePerLifetimeScope3. InstancePerMatchingLifetimeScope4. SingleInstance

Applying Autofac

• Let’s see how we can use DI and Autofac on a big project.

• First, how one might normally create the project without using DI.

• Second, how to create it with DI.

Common 3-tier App without DI

• Not “wrong,” but not an inherent guarantee of loose coupling

• Build Data, then BI, then UI. (bottom-up)

• The layers really are tightly coupled together, like the domain entities from the data layer.

• Hard to test.

• Config file dependent.

Advanced Configurationg (for more complex APIs)

Builder.RegisterType<Chicken>().As<IIngredient>(); Builder.RegisterType<Steak>().As<IIngredient>();Last one wins, unless you ask for an array of IIngredient’s.

Builder.RegisterType<Chicken>().Named<IIngredient>(“chicken”); Builder.RegisterType<Steak>().Named<IIngredient>(“steak”);Can also “name” your registrations.

This allows you to do many things when working with multiple components with the same interface, often with lambda expressions.Builder.RegisterType<Meal>().As<IMeal>().WithParameter( (p,c)=>true,(p,c)=>new[] {c.ResolveNamed<IIngredient>(“chicken”), c.ResolveNamed<IIngredient>(“steak”)});

Also, if your constructor has a string, number, enum as a parameter, it is possible to register that string as a component, or pass them in as a NamedParameter.

Summary• Use DI to enable loose coupling and to make code

more maintainable.• DI is just a set of good patterns, like programming to

an interface.• Using DI can change the way you code (for the

better) because of the good patterns.• There are several DI tools to choose from and

Autofac is good choice.• Use DI on your next project!

Resources• Autofac.org

• Book: “Dependency Injection in .NET” by Mark Seemann. http://www.manning.com/seemann/

• Podcast with Autofac creator http://www.dotnetrocks.com/default.aspx?showNum=450

• Advanced relationship types with Autofac http://nblumhardt.com/2010/01/the-relationship-zoo/

• Stackoverflow.com