Dependency Injection

And using an Inversion of Control (IoC) container

What is Dependency Injection

• Giving an object instance it’s variables

Dependency Non-Injection

public class Whatever{ private DbStuff _db; This is a variable

public Whatever() { _db = new DbStuff(); And Whatever } depends on it so it creates it public void DoIt() { _db.GetData(); }}

And this is bad for all kinds of reasons…

Single Responsibility Principle

• A class should have one, and only one, reason to change.

• We switch from SQL Server to Oracle and our Whatever class needs to change

Dependency Injection

public class Whatever{ private DbStuff _db;

public Whatever(DbStuff database) { _db = database; The ‘new’ keyword } is outta there

public void DoIt() { _db.GetData(); }}

Win

• Our Whatever class still depends on DbData but it is not responsible for it

• By adhering to SRP through dependency injection we increase cohesion

But wait! We still have a problem

Dependency Inversion Principle

• Depend on abstractions, not on concretions.

• We can improve the situation by depending on an interface or abstract class

Dependency Injection v 2.0

public class Whatever{ private IDbStuff _db; Better

public Whatever(IDbStuff database) { _db = database; life is good }

public void DoIt() { _db.GetData(); }}

To summarize, DI is about passing instance variables

Benefits

• High cohesion because classes are focused on doing one thing really well

• Testability

IDbStuff data = new FakeDbWithBadData();

var test = new Whatever(data);

Assert.Throws(Exception,test.DoIt());The class under

test did not have to change. Magic!

private readonly SystemConfiguration _configuration;private readonly IWorkorderEntityBuilder _entityBuilder;

public NewEntityWorkorderManager(IWorkorderRepository workorderRepository, IMessageRepository messageRepository, IWorkorderEntityBuilder entityBuilder, SystemConfiguration configuration, ICityworksRepository cityworksRepository) : base(workorderRepository, messageRepository, cityworksRepository, configuration) { _entityBuilder = entityBuilder; _configuration = configuration; }

Inversion of Control Containers

(IoC is a terrible term but we’re stuck with it. But maybe we’ll use container

instead. At least it’s shorter.)

Manage Dependencies

• DI makes for cohesive, loosely couple software

• But also more moving parts

• IoC containers exist to make dependency injection easier and more predictable

ContainersA Short List

• Spring• Spring.NET• Pico• Castle Windsor• StructureMap

• Ninject• Autofac• Unity• Glassfish and any EJB

3.0 app server

Workflow

Create a registry at application startup

Wire up dependencies in one place• Abstractions• Cascading dependencies• Auto-wiring• Lifestyle/instance

management

Ask the container for an instance

ForRequestedType<ISpatialQuery>() .TheDefaultIsConcreteType<SpatialQueryGenericClient>();

ForRequestedType<ISettingRepository>()

.TheDefault.Is.OfConcreteType<ApplicationSettingReposi

tory>()

.CtorDependency<IUnitOfWork>("unitOfWork")

.Is(u => u.TheInstanceNamed(Resources.WCSDatasource));

var settings = ObjectFactory.GetInstance<ISettingRepository>();

Autowiring Is A Big Win

Things depend on things depend on things…

CoreMessageProcess

GisDirectQuery

var processor = ObjectFactory.GetInstance<IMessageProcessor>();

Features

• Many other features but that’s the core

• Manage lifetime of objects– Singleton, per-thread, per-session

• XML configuration