Unity and SharePoint – Part 1

I thought I would start a new blog post series about how to use dependency injection in SharePoint, and more specific the Patters and Practices implementation of such a pattern, Unity.

Unity and SharePoint  – Part 2
Unity and SharePoint – Part 3

Here are some useful links along the lines of this topic:
How To: Enable Unity in a SharePoint Application
CodePlex: Unity
CodePlex: EntLib

 
First of all, why use the Unity framework and not something else?
Well, the answer for that is pretty simple. Most customers that I come in contact with will not allow anything into their applications that doesn´t say Microsoft.
I´m not saying that Unity is the best one, but I kinda like it anyway, but here is an excellent list of some other frameworks out there if you are interested:

ListOfNETDependencyInjectionContainersIOC

This first part will have some background details on dependency injection in general and then I´ll come into the real implementation in later posts.
Ok, to start of with have a look a these two alternatives of a class called Book.

public class Book
{
    private IBookRepository repository;
 

    public Book()
    {
        this.repository = new MyBookRepository();
    }
}

 

 
public class Book
{
    private IBookRepository repository;
 
    public Book(IBookRepository repository)
    {
        this.repository = repository;
    }
}

The class Book is said to have a dependency on an instance of an IBookRepository.
In the first Book class can only work together with MyBookRepository but the second Book class will work together with any implementation of the IBookRepository.
This particular example of DI is called constructor injection.

Pros with this:
Well, the benefit is that we have made the Book class testable because we could easily make a fake implementation of the interface and instantiate a new Book with that.
We could also just as easy change the implementation if the interface without changing the core inner workings of the Book class, that´s good.
We have also “forced” this little application into an architecture it might not have used otherwise, a well-designed and maintainable application is never bad.

A caller, the part of code that needs to create a new Book, on the other hand would need to know where to get a hold of an implementation of the IBookRepository which in fact means that the caller needs to know some of the inner workings of that class.
Because of this fact we often use a sort of factory (Dependency Locator or Dependency LookUp) to handle this for us. Then we only need to have a reference to that factory.
On the other hand, the factory and in return the caller would need all the references that MyBookRepository has (for instance, a reference to the Microsoft.SharePoint.dll).

The best thing would be if we had an external party that we could ask to provide us with an implementation of the IBookRepository without that party needing to have a reference to MyBookRepository…that is called a Inversion Of Control (IoC) container.

Some pros of an IOC container are:

  • minimize ”glue code”…code that only exist in order to “glue together” the application
  • creation of components in an controlled manner
  • handle all dependencies externally so the code wouldn´t need to know about them
  • Testability

If we were using Unity, the code to create a Book could look something like this:

    IUnityContainer container;
 

    public Book InstanceOfBook
    {
        get
        {
            IBookRepository repository = container.Resolve<IBookRepository>();
            Book b = new Book(repository);
           
            return b;
        }
    }

First of all we need to get an instance of the UnityContainer (IoC). Then we will ask the container to supply us with an implementation.
We will look more in detail on how Unity works and how to configure it in future posts.

UPDATE 090309:
If you speak Swedish, I found a great article that explains this pattern here.

Advertisements

, , , , ,

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: