Ninject EF4, Repository and Unit of Work

Question

I have several projects in my solution which access the same data so I am implementing data access later in a separate project. Currently I am using EF4, a generic repository and a Unit Of Work pattern. I have designed my data access to support dependency injection and I want to use Ninject. Here is a sample of what I have so far

public class Account 
{
    public int Id { get; set; }
    public Guid WebId { get; set; }
    public string Firstname { get; set; }
    public string Lastname { get; set; }
    public string Email { get; set; }
    public string Address { get; set; }
    public string Mobile { get; set; }

}

public interface IRepository<T>
{
    IEnumerable<T> Get(Expression<Func<T, bool>> filter, Func<IQueryable<T>);
    T GetById(int id);
    void Update(T dinner);
    void Insert(T dinner);
    void Delete(int id);
    void Save();
}

I also have a Repository Implementation which I won't post it here for space.

My UnitOfWork looks like this

public class UnitOfWork
{        
    private Repository<Account> _accountRepository;
    public IRepository<Account> AccountRepository
    {
        get
        {
            if (this._accountRepository == null)
            {
                _accountRepository = new Repository<Account>();
            }
            return _accountRepository;
        }
    }       
}

How and where do I set up ninject to auto resolve my Repository so I can use the interface and not need to instantiate it in my unit of work. Is this the right thing to do or am I getting the point of DI all wrong? Here is what I think I want my unit of work class to look like

public class UnitOfWork
{
    IKernel _kernel;

    public UnitOfWork()
    {
        _kernel = new StandardKernel();
    }

    private IRepository<Account> _accountRepository;

    public IRepository<Account> AccountRepository
    {
        get
        {
            if (this._accountRepository == null)
            {
                _accountRepository = _kernel.Get<IRepository<Account>>();;
            }
            return _accountRepository;
        }
    }

}

Answer 1

Dependency Injection tends to use a concept known as a composition root. This is a single place in your application where the composition of the object graphs for your application take place.

You do not use a dependency injection container in a library, per se. Your library may include objects that can be injected, but it tends to be an application based tool, not a library based tool.

What this means is that if you are creating a library only, you would not use a dependency injection container in it, or configure a container in it. Instead, you would create your library to work with dependency injection from your application. In your case, you would simply design your Repository, Unit of Work, etc.. to accept its dependencies via constructor injection. Then, in your application that uses your library you would use a DI container (such as Ninject) to configure how objects get created.

This does a number of things. First, it allows the application to control how objects are created. For instance, if you're using your library in a web app, then you can configure it to create an instance of your repository that lives for the life of one request. If your library did this, then you would have no control over this at the application level.

Second, if you use a DI container in your library, then you would also need a DI container in your app, thus you would end up with two DI containers, and that could cause various conflicts. There should only be one DI container in an application in most cases.

Finally, you are committing a classic newbie blunder. You are confusing the DI container, with the concepts of DI itself. DI is the way in which you design your classes, in particular how they accept dependencies from outside the objects.

A DI Container is a tool used to achieve DI, not DI in and of itself.

TL;DR

Do not design libraries to have their own DI container.