Inversion of control

Amirkabir University of Technology (Tehran Polytechnic)- Fall 2011
Dependency Injection and Inversion
of Control
Developing flexible, reusable and testable software
Moslem Rashidi

Something about the author
• This pattern was introduced in 2004 by Martin Fowler
• Martin Fowler is an author and
international speaker on software
development, specializing in object-oriented
analysis and design, UML, patterns and
agile software development.
• In March 2000, he became Chief Scientist at ThoughtWorks, a systems
integration and consulting company.

Intent
Intent of Dependency injection pattern:
It refers to the process of supplying an
external dependency to a software
component

What is a “Dependency”?
Some common dependencies include:
• Application Layers
– Data Access Layer & Databases
– Business Layer
• External services & Components
– Web Services
– Third Party Components
• Framework Components
– File Objects (File.Delete(…), Directory.Exists(…))
– Web Objects (HttpContext, Session, Request, etc)

Loosely Coupled Systems
• Good OO Systems – organised as web of interacting objects
• Goal – High cohesion, low coupling
• Advantages of low coupling
– Extensibility
– Testability
– Reusability
• Not so easy to achieve!

A Concrete Example – A Trade Monitor

Trade Monitor – The design
• TradeMonitor is coupled to LimitDao – this is not good!
– Extensibility – what if not database but distributed cache
– Testability – where do the limits for test come from?
– Reusability – logic is fairly generic . . .
public class TradeMonitor
{
private LimitDao limitDao;
public TradeMonitor()
{
limitDao = new LimitDao();
}
public bool TryTrade(string symbol, int amount)
{
int limit = limitDao.GetLimit(symbol);
int exposure = limitDao.GetExposure(symbol);
return (exposure + amount > limit) ? false : true;
}
}
public class LimitDao
{
public int GetExposure(string symbol)
{
// Do something with the database
}
public int GetLimit(string sysmbol)
{
// Do something with the database
}
}
limitDao = new LimitDao();

Trade Monitor – The Design Refactored (1)
• Introduce interface/implementation separation
– Logic does not depend on DAO anymore.
– Does this really solve the problem?
{
private ILimitRepository limitRepository;
{
limitRepository = new LimitDao();
}
{
. . .
}
}
public interface ILimitRepository
{
int GetExposure(string symbol);
int GetLimit(string symbol);
}
limitRepository = new LimitDao();
• The constructor still has a static dependency on DAO

• Introduce Factory
• TradeMonitor decoupled from LimitDao
public class LimitFactory
{
public static ILimitRepository GetLimitRepository()
{
return new LimitDao();
}
}
{
{
limitRepository = LimitFactory.GetLimitRepository();
}
{
. . .
}
}
LimitFactory
TradeMonitor
<<interface>>
LimitRepository
LimitDao
<<creates>>
return new LimitDao();
• LimitDao still tightly-coupled albeit to Factory

• Introduce ServiceLocator
• This gives us extensibility, testability, reusability
public class ServiceLocator
{
public static void RegisterService(Type type, object impl)
{. . .}
public static object GetService(Type type)
{. . .}
}
{
{
object o =
ServiceLocator.GetService(typeof(ILimitRepository));
limitRepository = o as ILimitRepository;
}
{
. . .
}
}

ServiceLocator - Problems
• Sequence dependence
• Cumbersome setup in tests
• Service depends on infrastructure code, (ServiceLocator)
• Code needs to handle lookup problems
• Aren’t these problem minor?
Why settle for something we know has issues?

A Different View
• What about adding a setter and let something else worry about creation
and resolution?
{
{
}
public ILimitRepository Limits
{
set { limitRepository = value;}
}
}
• The dependencies are injected from the outside
• Components are passive and are not concerned with locating or
creating dependencies
This is Setter Dependency Injection

Another Idea
• Why not just use the constructor?
{
public TradeMonitor(ILimitRepository limitRepository)
{
this.limitRepository = limitRepository;
}
}
• No setters for dependent components, (obviously)
• One-shot initialisation – components are always initialised correctly
• All dependencies are clearly visible from code
• It is impossible to create cyclic dependencies
This is Constructor Dependency
Injection

What about Inversion of Control?
• Dependency Injection - one example of IoC design principle.
• Also known as the Hollywood Principle
– Don’t call us, we’ll call you!
• Objects rely on their environment to provide dependencies rather than
actively obtaining them.
• Inversion of Control can make the difference between a library and a
framework.

IoC Containers
• There are still some open questions
– Who creates the dependencies?
– What if we need some initialisation code that must be run after
dependencies have been set?
– What happens when we don’t have all the components?
• IoC Containers solve these issues
– Have configuration – often external
– Create objects
– Ensure all dependencies are satisfied
– Provide lifecycle support

It Gets Better
• We can use reflection to determine dependencies – no need for config
files.
• Most IoC containers support auto-wiring.
• Make components known to container.
• Container examines constructors and determines dependencies.
• Auto-wiring provides other benefits.
• Less typing, especially long assembly names.
• Static type checking by IDE at edit time.
• More intuitive for developer.

IoC Containers and Features
Container Setter
DI
Ctor
DI
External
config
Code
config
Auto-
wiring
Lifecycle
support`
Url
System.ComponentModel a a Part of .Net framework
PicoContainer.Net a a a a a http://picocontainer.org
Windsor a a a ? a http://www.castleproject.org
StructureMap a a a P a http://sourceforge.net/projects/structuremap
Spring.Net a a a ? a a http://www.springframework.net/
ObjectBuilder a a a a ?? a http://msdn.microsoft.com
?? = More investigation
? = Setter based DI required for primitive dependencies
P = Partial still requires configuration to point to assemblies to scan

The Solution – Test Case
[TestFixture]
public class TradeMonitorTest
{
[Test]
public void MonitorBlocksTradesWhenLimitExceeded()
{
DynamicMock mockRepository = new DynamicMock(typeof(ILimitRepository));
mockRepository.SetupResult('GetLimit', 1000000, new Type[] { typeof(string) });
mockRepository.SetupResult('GetExposure', 999999, new Type[] { typeof(string) });
TradeMonitor monitor = new TradeMonitor((ILimitRepository)mockRepository.MockInstance);
Assert.IsFalse(monitor.TryTrade('MSFT', 1000), 'Monitor should block trade');
}
}
{
private ILimitRepository repository;
public TradeMonitor(ILimitRepository repository) { this.repository = repository; }
{
int limit = repository.GetLimit(symbol);
int exposure = repository.GetExposure(symbol);
return ((amount + exposure) <= limit);
}
}

The Solution – Using the Windsor Container
• Code configuration
IWindsorContainer container = new WindsorContainer();
container.AddComponent('limitRepository', typeof(ILimitRepository), typeof(LimitDao));
container.AddComponent('tradeMonitor', typeof(TradeMonitor));
TradeMonitor monitor = (TradeMonitor)container['tradeMonitor'];
monitor.TryTrade('MSFT', 1000);
• External configuration
IWindsorContainer container = new WindsorContainer('config.xml');
TradeMonitor monitor = (TradeMonitor)container['tradeMonitor'];
monitor.TryTrade('MSFT', 1000);
<configuration>
<components>
<component id='limitRepository' service='AAABank.ILimitRepository, AAABank'
type='AAABank.LimitDao, AAABank' />
<component id='tradeMonitor' type='AAABank.TradeMonitor, AAABank' />
</components>
</configuration>

The Solution – Complex Configuration
• What if components take parameters?
public class LimitDao
{
public LimitDao(string connectionString) {…}
}
{
public TradeMonitor(string[] monitoredSymbols) {…}
}
<configuration>
<components>
<component id='limitRepository' service='AAABank.ILimitRepository, AAABank'
type='AAABank.LimitDao, AAABank'>
<connectionString>Data Source=AServer;Initial Catalog=BankDB;User ID=sa</connectionString>
</component>
. . .
<configuration>
<components>
<component id='tradeMonitor' type='AAABank.TradeMonitor, AAABank'>
<monitoredSymbols>
<array>
<elem>MSFT</elem>
<elem>TWUK</elem>
</array>
</monitoredSymbols>
. . .

Many other possibilities
• Container creates objects – but what objects?
• Can return proxy – no need for MarshalByRef inheritance.
• Object instance caching.
• Aspect Oriented Programming (concerns ,advice ,join point, pointcut).
• Remoting by configuration.
• Automatic Web Service creation.
• . . .

Summary
• Container based DI facilitates: -
– Testability
– Extensibility
– Reusability
• Makes the difference between framework and library
– Not just use but extend
• Essential for complex Domain Driven Design
– Easier to separate 'infrastructure' from business logic

Questions?

Inversion of control

Related slideshows

More Related Content

Inversion of control