Unity and SharePoint – Part 3

Ok, this time I´ll be a little bit more hands on, I hope. The previous posts have been about Dependency Injection and Inversion of Control in general and then how to configure unity with xml. Here are the links to those previous post

Unity and SharePoint – Part 2
Unity and SharePoint – Part 1

This time though, I´d like show a more concrete example.
There will be a little bit of DDD (Domain Driven Design), a new baby of mine, included in this example but that is not the main point. Let´s lay out the problem:

In my domain model (DDD concept) I have an entity called Book. The Book class (entity) has a dependency on an instance of the IBookRepository. It uses the repository to communicate with the backend (which in this case happens to be SharePoint). The Book constructor looks like this:

[InjectionConstructor]
public Book([Dependency] IBookRepository bookRepository)
{
this._BookRepository = bookRepository;
}

The attribute, InjectionConstructor, tells unity to use this constructor when resolving an instance through the container. The dependency attribute on the parameter tells unity to look for the default (since I didn´t name it) instance of IBookRepository in the container. This will make unity find the mapping I just did which looks like (from the other posts):

<typeAliases>
<!-- Lifetime managers -->
<typeAlias alias="singleton"
type="Microsoft.Practices.Unity.ContainerControlledLifetimeManager,
Microsoft.Practices.Unity, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<typeAlias alias="IBookRepository"
type="JL.DomainModel.Repositories.IBookRepository,
JL.DomainModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6dbfe176cdfd49fb"/>
<typeAlias alias="BookRepository"
type="JL.Infrastructure.Repositories.BookRepository,
JL.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6dbfe176cdfd49fb"/>
</typeAliases>
<containers>
<container>
<types>
<type type="IBookRepository" mapTo="BookRepository">

	<lifetime type="singleton" />
</type>

I have made the repository mapping a singleton (I only need to construct it once). In order to test this I´m simply going to “force” the container to resolve two books for me. I will expect it to call the constructor of BookRepository (the concrete implementation of IBookRepository) only once (since it is a singleton.

So running this code:

As expected, the constructor is called the first time (by unity).

…and the second time, no it isn´t called. So it works, unity gives me the same instance of IBookRepository.

And when debugging the construction of Book you will see this:

Unity has made the mapping between IBookRepository and BookRepository which are in different assemblies (and different parts of the application tiers) work for me and injected that into Book. Now we really have loose coupling between the different tiers.

Book, which is in the domain layer, only need to know how to communicate through the interface IBookRepository (which also resides in the domain layer). The concrete BookRepository resides in the infrastructure layer which the domain layer knows nothing about. Some people call this the onion architecture.