Exercises in .NET with Andras Nemes

SOLID design principles in .NET: the Dependency Inversion Principle Part 2, DI patterns

In the previous post we went through the basics of DIP and DI. We’ll continue the discussion with the following questions: how to implement DI?

The main source in the series on Dependency Injection is based on the work of Mark Seemann and his great book on DI.

Flavours of DI

I hinted at the different forms of DI in the previous post. By far the most common form is called Constructor Injection:

public ProductService(IProductRepository productRepository)
{
	_productRepository = productRepository;
}

Constructor injection is the perfect way to ensure that the necessary dependency is always available to the class. We force the clients to supply some kind of implementation of the interface. All you need is a public constructor that accepts the dependency as a parameter. In the constructor we save the incoming concrete class for later use, i.e. assign to a private variable.

We can introduce a second level of security by introducing a guard clause:

public ProductService(IProductRepository productRepository)
{
       if (productRepository == null) throw new ArgumentNullException("ProductRepo");
	_productRepository = productRepository;
}

It is good practice to mark the private field readonly, in this case the _productRepository, as it guarantees that once the initialisation logic of the constructor has executed it cannot be modified by any other code:

private readonly IProductRepository _productRepository;

This is not required for DI to work but it protects you against mistakes such as setting the value to null someplace else in your code.

Constructor injection is a good way to document your class to the clients. The clients will see that ProductService will need an IProductRepository to perform its job. There’s no attempt to hide this fact.

When the constructor is finished then the object is guaranteed to have a valid dependency, i.e. the object is in a consistent state. The following method will not choke on a null value where _productRepository is called:

public IEnumerable<Product> GetProducts()
{
	IEnumerable<Product> productsFromDataStore = _productRepository.FindAll();	
	return productsFromDataStore;
}

We don’t need to test for null within the GetProducts method as we know it is guaranteed to be in a consistent state.

Constructor injection should be your default DI technique in case your class has a dependency and no reasonable local defaults exist. A local default is an acceptable local implementation of an abstract dependency in case none is injected by the client. We’ll talk more about this a bit later. Also, try to avoid overloaded constructors because then you’ll need to rely on those local defaults if an empty constructor is used. In addition, having just one constructor greatly simplifies the usage of automated DI containers, also called IoC containers. If you don’t know what they are, then don’t worry about them for now. They are not a prerequisite for DIP and DI and they cannot magically turn tightly coupled code into a loosely coupled one. Make sure that you first understand how to do DI without such tools.

You can read briefly about them here. In short they are ‘magic’ tools that can initialise dependencies. In the above example you can configure such a container, such as StructureMap to magically inject a MyDefaultProductRepository when it sees that an IProductRepository is needed.

The next DI type in line is called Property injection. Property injection is used when your class has a good local default for a dependency but still want to enable clients to override that default. It is also called Setter injection:

public IProductRepository ProductRepository { get; set; }

In this case you obviously cannot mark the backing field readonly.

This implementation is fragile as by default all object types are set to null so ProductRepository will also be null. You’ll need to extend the property setter as follows:

public IProductRepository ProductRepository 
{
	get
	{
		return _productRepository;
	}
	set
	{
		if (value == null) throw new ArgumentNullException("ProductRepo");
		_productRepository = value;
	}
}

We’re still not done. There’s nothing forcing the client to call this setter so the GetProducts method will throw an exception. At some point we must initialise the dependency, maybe in the constructor:

public ProductService()
{
	_productRepository = new DefaultProductRepository();
}

By now we know that initialising an object with the ‘new’ keyword increases coupling between two objects so whenever possible accept the dependency in form of an abstraction instead.

Alternatively you can take the Lazy Initialisation approach in the property getter:

public IProductRepository ProductRepository 
{
	get
	{
		if (_productRepository == null)
		{
			_productRepository = new ProductRepository();
		}
		return _productRepository;
	}
	set
	{
		if (value == null) throw new ArgumentNullException("ProductRepo");
		_productRepository = value;
	}
}

We can go even further. If you want that the client should only set the dependency once without the possibility to alter it during the object’s lifetime then the following approach can work:

public IProductRepository ProductRepository 
{
	get
	{
		if (_productRepository == null)
		{
			_productRepository = new ProductRepository();
		}
		return _productRepository;
	}
	set
	{
		if (value == null) throw new ArgumentNullException("ProductRepo");
		if (_productRepository != null) throw new InvalidOperationException("You are not allowed to set this dependency more than once.");
		_productRepository = value;
	}
}

BTW this doesn’t mean that from now on you must never again use the new keyword to initialise objects. At some point you’ll HAVE TO use it as you can’t connect the bits and pieces using abstractions only. E.g. this is invalid code:

ProductService ps = new ProductService(new IProductRepository());

No, unless you have some IoC Container in place you’ll need to go with what’s called the poor man’s dependency injection:

ProductService ps = new ProductService(new DefaultProductRepository());

Where DefaultProductRepository implements IProductRepository.

Coming back to Property injection, you can use it whenever there’s a well functioning default implementation of a dependency but you still want to let your users provide their own implementation. In other words the dependency is optional. However, this choice must be a conscious one. As there’s nothing forcing the clients to call the property setter your code shouldn’t complain if the dependency is null when it’s needed. That’s a sign saying that you need to turn to constructor injection instead. In case you don’t really need a local default then the Null Object pattern can come handy. If the local default is part of the .NET base class library then it may be an acceptable approach to use it.

As you see the last version of the property getter-setter is considerably more complex than taking the constructor injection approach. It looks easy at first, just insert a get;set; type of property but you soon notice that it’s a fragile structure.

A third way of doing DI is called method injection. It is used when we want to ensure that we can inject a different implementation every time the dependency is used:

public IEnumerable<Product> GetProducts(IProductDiscountStrategy productDiscount)
{
	IEnumerable<Product> productsFromDataStore = _productRepository.FindAll();
	foreach (Product p in productsFromDataStore)
	{
		p.AdjustPrice(productDiscount);
	}
	return productsFromDataStore;
}

Here we apply a discount strategy on each product in the iteration. The actual strategy may change a lot, it can depend on the season, the loyalty scheme, the weather, the time of the day etc. As usual you can include a guard clause:

public IEnumerable<Product> GetProducts(IProductDiscountStrategy productDiscount)
{
	if (productDiscount == null) throw new ArgumentNullException("Discount strategy");
	IEnumerable<Product> productsFromDataStore = _productRepository.FindAll();
	foreach (Product p in productsFromDataStore)
	{
		p.AdjustPrice(productDiscount);
	}
	return productsFromDataStore;
}

In this approach it’s easy to vary the concrete discount strategy every time we call the GetProducts method. If you had to inject this into the constructor then you’d need to create a new ProductService class every time you want to apply some pricing strategy. In case the method doesn’t use the injected dependency you won’t need a guard clause. This may sound strange at first; why have a dependency in the signature if it is not used in the method body? Occasionally you’re forced to implement an interface where the interface method defines the dependency – more on that in the post about the Interface Segregation Principle.

Patterns related to method injection are Factory and Strategy. Choosing the proper implementation to be injected into the GetProducts method will almost certainly depend on other inputs such as the choices the user makes on the UI. These patterns will help you solve that problem.

An example of method injection from .NET is the Contains extension method from LINQ:

bool IEnumerable<T>.Contains(T object, IEqualityComparer<T> comparer);

You can then provide your own version of the equality comparer.

The last type of DI we’ll discuss is making dependencies available through a static accessor. It is also called injection through the ambient context. It is used when implementing cross-cutting concerns.

What are cross-cutting concerns? Operations that may be performed in many unrelated classes and that are not closely related to those classes. A classic example is logging. You may want to log exceptions, performance data etc. I may want to log the time it takes the GetProducts method to return in the ProductService class. You could inject an ILogger interface to every class that needs logging but it introduces a large amount of pollution across your objects. Also, an ILogger interface attached to a constructor is not truly necessary for the dependent object to perform its real job. Logging is usually not part of the core job of services and repositories.

If you’re a web developer then you must have come across the HttpContext object at some point. It is an application of the ambient context pattern. You can always try and access that object and get hold of the current HTTP context which may or may not be available right there and then by its Current static property. You can construct your own Context object where you retrieve the current context using threads. A time provider context may look as follows:

public abstract class TimeProviderContext
{
	public static TimeProviderContext Current
	{
		get
		{
			TimeProviderContext timeProviderContext = Thread.GetData(Thread.GetNamedDataSlot("TimeProvider")) as TimeProviderContext;
			if (timeProviderContext == null)
			{
				timeProviderContext = TimeProviderContext.DefaultTimeProviderContext;
				Thread.SetData(Thread.GetNamedDataSlot("TimeProvider"), timeProviderContext);
			}
			return timeProviderContext;
		}
		set
		{
			Thread.SetData(Thread.GetNamedDataSlot("TimeProvider"), value);
		}
	}
	public static TimeProviderContext DefaultTimeProviderContext = new DotNetTimeProvider();

	public abstract DateTime GetTime { get; }
}

…where DotNetTimeProvider looks as follows:

public class DotNetTimeProvider : TimeProviderContext
{
	public override DateTime GetTime
	{
		get { return DateTime.Now; }
	}
}

The TimeProviderContext is abstract and has a static Current property to get hold of the current context. That’s the classic setup of the ambient context. Using the Thread object like that will ensure that each thread has its own context. There’s a default implementation which is the standard DateTime class from .NET. It’s important to note that the Current property must be writable so that clients can assign their own time providers by deriving from the TimeProviderContext object. This can be helpful in unit testing where ideally you want to control the time instead of waiting for some specific date. The local default makes sure that the client doesn’t get a null reference exception when calling the Current property.

For simplicity’s sake I only put a single abstract method in this class to get the date but ambient context classes can provide as many properties as you need.

You can then use this context in client classes as follows:

public DateTime TestTime()
{
	return TimeProviderContext.Current.GetTime;
}

Ambient context should be used with care. Use it only if you want to make sure that a cross-cutting concern is available anywhere throughout your application. In that case it may be futile to force objects to take on dependencies they may not need now but might do so at some point in the future:

public IProductRepository ProductRepository 
{
	get
	{
		if (_productRepository == null)
		{
			_productRepository = new ProductRepository(TimeProviderContext.Current);
		}
		return _productRepository;
	}
}

…where ProductRepository looks as follows:

public class ProductRepository : IProductRepository
{	

	public ProductRepository(TimeProviderContext timeProviderContext)
	{
		//do nothing with the time provider context right now but it may be needed later
	}

	public IEnumerable<Product> FindAll()
	{
		return new List<Product>();
	}
}

That only increases the coupling between objects and pollutes your object structure.

A disadvantage with the ambient context approach is that the consuming class carries an implicit dependency. In other words it hides from the clients that it needs a time provider in order to perform its job. If you put the TestTime() method shown above in the ProductService class then there’s no way for the client to tell just by looking at the interface that ProductService uses this dependency. Also, callers of the TestTime method will get different results depending on the actual context and it may not be transparent to them why this happens without looking at the source code.

There’s actually a technical term to describe this “openness” that Eric Evans came up with: Intention-revealing interfaces. An API should communicate what it does by its public interface alone. A class using the ambient context does exactly the opposite. Clients may know of the existence of a TimeProviderContext class but will probably not know that it is used in ProductService.

There are cross cutting concerns that only perform some task without returning an answer: logging exceptions and performance data are such cases. If you have that type of scenario then a technique called Interception is something to consider. We’ll look at interception briefly it the blog post after the next one.

Conclusion

Of the four techniques discussed your default choice should always be Constructor Injection in case there’s a dependency within your class. If the dependency varies from operation to operation then Method Injection is good candidate.

Then you can ask the question if the dependency represents a cross-cutting concern. If not and a good local default exists then you can go down the Property Injection path. Otherwise if you need some return value from the cross-cutting concern dependency and you have a good local default in case Context.Current is null then Ambient Context can help. Else if this dependency only has void methods then take a look at Interception.

When in doubt, especially if you are trying to pick a strategy between Constructor Injection and another variant then pick Constructor injection. Things can never go fatally wrong with that option.

View the list of posts on Architecture and Patterns here.

SOLID design principles in .NET: the Dependency Inversion Principle and the Dependency Injection pattern

Introduction

The Dependency Inversion Principle (DIP) helps to decouple your code by ensuring that you depend on abstractions rather than concrete implementations. Dependency Injection (DI) is an implementation of this principle. In fact DI and DIP are often used to mean the same thing. A key feature of DIP is programming to abstractions so that consuming classes can depend on those abstractions rather than low-level implementations. DI is the act of supplying all classes that a service needs rather than letting the service obtain its concrete dependencies. The term Dependency Injection may first sound like some very advanced technology but in reality there are absolutely no complex techniques behind it. As long as you understand abstractions and constructors and methods that can accept parameters you’ll understand DI as well.

Another related term is Inversion of Control, IoC. IoC is an older term than DI. Originally it meant a programming style where a framework or runtime controlled the programme flow. Sticking to this definition software that is developed with .NET uses IoC – in this case .NET is the controlling framework. You hook up to its events, lifetime management etc. You are in control of your methods and references but .NET provides the ultimate glue. Nowadays we’re so used to working with frameworks that we don’t care – we’re actually happy that we don’t need to worry about tedious infrastructure stuff. With time IoC drifted away to mean Inversion of Control Containers which are mechanisms that control dependencies. Martin Fowler was the one who came up with the term Dependency Injection to mean this particular flavour of IoC. Thus, DI is still the correct term to describe the control over dependencies although people often use IoC instead.

DIP is a large topic so it will span several posts to discuss it thoroughly. However, one important conclusion up front is the following:

The frequency of the ‘new’ keyword in your code is a rough estimate of the degree of coupling in your object structure.

A side note: in the demo I’ll concentrate on interfaces but DI works equally well with abstract classes.

The main source in the series on Dependency Injection is based on the work of Mark Seemann and his great book on DI.

What are dependencies?

Dependencies can come in different forms.

A framework dependency is your choice of the development framework, such as .NET. You as a .NET developer are probably comfortable with that dependency as it’s unlikely to change during the product’s lifetime. Most often if you need the product to run on a different framework then it will be rewritten for that platform in a different language without discarding the original product. As this dependency is very unlikely to change and it’s a very high level dependency we don’t worry about it in this context.

Third party libraries introduce a lower level dependency that may well change over time. If a class depends on an external dll then that class may be difficult to test as we need that library to be in a consistent state when testing. However, some of those dependencies may never change. E.g. if I want to communicate with the Amazon cloud in code then it’s best to download and reference the Amazon .NET SDK and use that for entire lifetime of the product. It’s unlikely that I will write my own SDK to communicate with the Amazon web services.

Databases store your data and they can come in many different forms: SQL Server, MySQL, MongoDb, RavenDb, Oracle etc. You may think that an application will never change its storage mechanism, but you’ll better be prepared and abstract it away behind a repository as we’ll see in the demo.

Some other less obvious dependencies include the File System, Emails, Web services and other networking technologies.

System resources such as the Clock to get the current time. You may think that’s unnecessary to abstract that away. After all, why would you ever write your own time provider if the System Clock is available? Think of unit testing a method that depends on time: a price discount is given between 5pm and 6pm on every Friday. How would you unit test that logic? Do you really wait until 5pm on a Friday and hope that you can make the test pass before 6pm? That’s not too clever, as your unit test can only run during that time. So there’s a valid point in abstracting away system resources as well.

Configuration in general, such as the app settings you read from the config file.

The new keyword, as hinted at in the introduction, generally points to tighter coupling and an introduction of an extra dependency. As soon as you write var o = new MyObject() in your class MyClass then MyClass will be closely dependent on MyObject(). If MyObject() changes its behaviour then you have to be prepared for changes and unexpected behaviour in MyClass as well. Using static methods is no way out as your code will depend on the object where the static method is stored, such as MyFactory.GetObject(). You haven’t newed up a MyFactory object but your code is still dependent on it.

Depending on threading-related objects such as Thread or Task can make your methods difficult to test as well. If there’s a call to Thread.Sleep then even your unit test will need to wait.

Anytime you introduce a new library reference you take on an extra dependency. If you have a 4 layers in your solution, a UI, Services, Domains and Repository then you can glue them together by referencing them in Visual Studio: UI uses Services, Services use the Repo etc. The degree of coupling is closely related to how painful it is to replace those layers with new ones. Do you have to sit for days in front of your computer trying to reconnect all the broken links or does it go relatively fast as all you need to do is inject a different implementation of an abstraction?

Getting random numbers using the Random object also introduces an extra dependency that’s hard to test. If your code depends on random numbers then you may have to run the unit test many times before you get to test all branches. Instead, you can provide a different implementation of generating random numbers where you control the outcome of this mechanism so that you can easily test your code.

I’ve provided a hint on how to abstract away built-in .NET objects in your code at the end of this post.

Demo

In the demo we’ll use a simple Product domain whose price can be adjusted using a discount strategy. The Products will be retrieved using a ProductRepository. A ProductService class will depend on ProductRepository to communicate with the underlying data store. We’ll first build the classes without DIP in mind and then we’ll refactor the code. We’ll keep all classes to a minimum without any real implementation so that we can concentrate on the issues at hand. Open Visual Studio and create a new console application. Add the following Product domain class:

public class Product
{
	public void AdjustPrice(ProductDiscount productDiscount)
	{
	}
}

…where ProductDiscount looks even more simple:

public class ProductDiscount
{
}

ProductRepository will help us communicate with the data store:

public class ProductRepository
{
	public IEnumerable<Product> FindAll()
	{
		return new List<Product>();
	}
}

We connect the above objects in the ProductService class:

public class ProductService
{
	private ProductDiscount _productDiscount;
	private ProductRepository _productRepository;

	public ProductService()
	{
		_productDiscount = new ProductDiscount();
		_productRepository = new ProductRepository();
	}

	public IEnumerable<Product> GetProducts()
	{
		IEnumerable<Product> productsFromDataStore = _productRepository.FindAll();
		foreach (Product p in productsFromDataStore)
		{
			p.AdjustPrice(_productDiscount);
		}
		return productsFromDataStore;
	}
}

A lot of code is still written like that nowadays. This is the traditional approach in programming: high level modules call low level modules and instantiate their dependencies as they need them. Here ProductService calls ProductRepository, but before it can do that it needs to new one up using the ‘new’ keyword. The client, i.e. the ProductService class must fetch the dependencies it needs in order to carry out its tasks. Two dependencies are created in the constructor with the ‘new’ keyword. This breaks the Single Responsibility Principle as the class is forced to carry out work that’s not really its concern.

The ProductService is thus tightly coupled to those two concrete classes. It is difficult to use different discount strategies: there may be different discounts at Christmas, Halloween, Easter, New Year’s Day etc. Also, there may be different strategies to retrieve the data from the data store such as using an SQL database, a MySql database, a MongoDb database, file storage, memory storage etc. Whenever those strategies change you must update the ProductService class which breaks just about every principle we’ve seen so far in this series on SOLID.

It is also difficult to test the product service in isolation. The test must make sure that the ProductDiscount and ProductRepository objects are in a valid state and perform as they are expected so that the test result does not depend on them. If the ProductService sends an email then even the unit test call must send an email in order for the test to pass. If the emailing service is not available when the test runs then your test will fail regardless of the true business logic of the method under test.

All in all it would be easier if we could provide any kind of strategy to the ProductService class without having to change its implementation. This is where abstractions and DI enters the scene.

As we can have different strategies for price discounts and data store engines we’ll need to introduce abstractions for them:

public interface IProductDiscountStrategy
{
}

public interface IProductRepository
{
	IEnumerable<Product> FindAll();
}

Have the discount and repo classes implement these interfaces:

public class ProductDiscount : IProductDiscountStrategy
{
}

public class ProductRepository : IProductRepository
{
	public IEnumerable<Product> FindAll()
	{
		return new List<Product>();
	}
}

When we program against abstractions like that then we introduce a seam into the application. It comes from seams on cloths where they can be sewn together. Think of the teeth – or whatever they are called – on LEGO building blocks. You can mix and match those building blocks pretty much as you like due to the standard seams they have. In fact LEGO applied DIP and DI pretty well in their business idea.

Let’s update the ProductService class step by step. The first step is to change the type of the private fields:

private IProductDiscountStrategy _productDiscount;
private IProductRepository _productRepository;

You’ll see that the AdjustPrice method of Product now breaks so we’ll update it too:

public void AdjustPrice(IProductDiscountStrategy productDiscount)
{
}

Now the Product class can accept any type of product discount so we’re on the right track. See that the AdjustPrice accepts a parameter of an abstract type? We’ll look at the different flavours of DI later but that’s actually an application of the pattern called method injection. We inject the dependency through a method parameter. We’ll employ constructor injection to remove the hard dependency on the ProductRepository class within ProductService:

public ProductService(IProductRepository productRepository)
{
	_productDiscount = new ProductDiscount();
	_productRepository = productRepository;
}

Here’s the final version of the ProductService class:

public class ProductService
{
	private IProductRepository _productRepository;

	public ProductService(IProductRepository productRepository)
	{
		_productRepository = productRepository;
	}

	public IEnumerable<Product> GetProducts(IProductDiscountStrategy productDiscount)
	{
		IEnumerable<Product> productsFromDataStore = _productRepository.FindAll();
		foreach (Product p in productsFromDataStore)
		{
			p.AdjustPrice(productDiscount);
		}
		return productsFromDataStore;
	}
}

Now clients of ProductService, possibly a ProductController in an MVC app, will need to provide these dependencies so that the ProductService class can concentrate on its job rather than having to new up dependencies. Obtaining the correct pricing and data store strategy should not be the responsibility of the ProductService. This relates well to the Open-Closed Principle in that you can create new pricing strategies without having to update the ProductService class.

It’s important to note that the ProductService class is now honest and transparent. It is honest about its needs and doesn’t try to hide the external objects it requires in order to fulfil its job, i.e. its dependencies are explicit. Clients using the ProductService class will know that it requires a discount strategy and a product repository. There are no hidden side effects and unexpected results.

The opposite case is a class having implicit dependencies such as the first version of the ProductService class. It’s not obvious for the caller that ProductService will use external libraries and it does not have any control whatsoever over them. In the best case if you have access to the code then you can inspect it and maybe even refactor it. The first version of ProductService tells the client that it suffices to simply create a new ProductService object and then it will be able to fetch the products. However, what do we do if the database is not present? Or if the prices are not correct due to the wrong discount strategy? Then comes the part where ProductService says ‘oh, sorry, I need database access before I can do anything, didn’t you know that…?”.

Imagine that you get a new job as a programmer. Normally all ‘dependencies’ that you need for your job are provided for you: a desk, a computer, the programming software etc. Now think how this would work without DI: you’ll have to buy a desk, get a computer within some specified price range, install the software yourself etc. That is the opposite of DI and that is how ProduceService worked before the refactoring.

A related pattern to achieve DI is the Adapter pattern. It provides a simple mechanism to abstract away dependencies that you have no control over, such as the built-in .NET classes. E.g. if your class sends emails then your default choice could be to use the built-in .NET emailing objects, such as MailMessage and SmtpClient. You cannot easily abstract away that dependency as you have no access to the source code, you cannot make it implement a custom interface, such as IEmailingService. The Adapter patter will help you solve that problem. Also, unit testing code that sends emails is cumbersome as even the test call will need to send out an email. Ideally we don’t test those external services so instead inject a mock object in place of the real one. How that is done? Start here.

View the list of posts on Architecture and Patterns here.