Question

What is the best way to abstract away 3rd party dependencies, when using Ninject with ASP.NET MVC?

Usually, I do something like this:

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

public class ProductRespository : IProductRepository
{
    public IEnumerable<Product> GetProducts()
    {
        ...
    }
}

And then in the controller:

public class ProductController : Controller
{
    private IProductRepository repository;

    public ProductController(IProductRepository repository)
    {
        this.repository = repository;
    }

    ...
}

And then I use Ninject to automatically inject the solid ProductRepository into the controller.

But how do I do this if the dependency is 3rd party? For example, I’m using FlickrNet.

public class ProductController : Controller
{
    private Flickr flickr;

    ...
}

I’d like to be able to abstract the Flickr object away into an interface so that I can use dependency injection and make it easier to unit test. I know I could create a ‘service’ type interface and then implement a class based off of that which would wrap the Flickr object.

But I would have to define a member in the interface corresponding to each member of the Flickr object, and then map each of these in the wrapper object. And there are lots and lots of members in the Flickr object.

Is there any better way to deal with this? My main goal is to make it easy to mock the Flickr dependency in unit tests.

Answer 1

Upgraded my comment to an answer.

This is not a problem with DI but a general architectural problem. You can either declare the controller as your abstraction layer or define a wrapper around the flickr component that implements a custom interface. If the methods on your 3rd party component consume more 3rd party classes you would need to abstract them away too and so on until you are down to only primitive values or more wrappers around 3rd party code. Depending on the complexity of that component this could mean a lot of mapping and wrapping.