{ independency injection }

There are a million and a half articles out there about Policy Injection and the Policy Injection Blocks (from Enterprise Library). Most of them are by my new favorite blogger, David Hayden. If you aren't familiar with Unity, check out these posts first.

The articles span the life-cycle of Unity from before Policy Injection was introduced and some of the actual type names change from article to article, so it wasn't as straight forward as I am going to make it here.

First of all, I didn't want to use a config file - I wanted to configure my policies in the same place I was configuring my dependencies; in the Global.asax code-behind.

It turns out that this is super easy!

Assuming you already have a reference to the Unity library "Microsoft.Practices.Unity", all you need to add is a reference to the "Microsoft.Unity.Interception" library, found in Microsoft Enterprise Library 4.1.

You probably already have a place where you are configuring your dependencies:

// Register for Dependency Injection

container.RegisterType<IDataContextProvider, DataContextProvider>();

Now all you need to do is setup the container with an extension that's called 'Interception' then configure each of the Interfaces you want to intercept with Policies. Like so:

Now, when you use Unity to resolve your objects, it will detect if any policies are decorated on the interface or the concrete class. If there are policies, Unity creates a transparent proxy object and executes your policies like it does in the Policy Application Blocks. Check out this article to see how to create handlers.

Now you are ready to place your "Policy Attributes" on your classes. Later, I will show you some of my favorite policies I have written for MVC.

As you know, I have recently become a huge fan of the Dependency Injection (DI) and Inversion of Control (IoC) patterns, but was stumped when trying to implement this pattern down to my data layer. I LOVE LinqToSQL, but I wasn't sure how I could make the Linq DataContext an abstract interface. I stumbled upon a great article discussing How to make the DataContext "Unit Testable". From this, I boiled down a version of an interface that was easy to implement in the DataContext.

An Interface for the DataContext: IDataContext

LinqToSql exposes Sql Server tables as theunmockable Table which is a sealed class. But LinqToSql namespace has an interface ITable which the Table type implements and that is easy to mock, also this ITable exposes InsertOnSubmit, InsertAllOnSubmit, DeleteOnSubmit, DeleteAllOnSubmit. So in our interface we exposed the ITable instead of that concrete Table which makes this partial Database class completely unit testable.

As you can see, all the basic functions of the DataContext exist for your consuming class.

Implement that Sucker

Now we need to implement this interface in our DataContext. Right-click on your DBML file, and select "View Code". This creates a partial class file for the DataContext. In it, you can implement the interface.

Example Usage

Now, your consuming classes are free to use the DataContext as the Interface "IDataContext" which can be mocked in Unit Tests.

publicclassSomeController

{

readonlyIDataContext _DataContext;

public SomeController(IDataContext dataContext)

{

_DataContext = dataContext;

}

publicvoid DoSomething()

{

var foo = _DataContext.GetQueryable<Foo>()

.SingleOrDefault(f => f.FooId == 1);

}

}

Conclusion

This demonstrates how you can make your DataContext an interface that is mockable and could be injected at runtime for DI. In the next article, I will show how you can create a generic repository using the IDataContext.