Ninject UnitOfWork confusion

Question

I use Ninject all the time with my MVC 3 applications, but I'm trying to change the Pattern for my Data Objects to use UnitOfWork and I'm having trouble figuring out how to get Ninject to handle this properly.

I know my implementation of classes work when they are constructed manually like this in my console application:

IDatabaseFactory factory = new DatabaseFactory();
IUnitOfWork worker = new UnitOfWork(factory);
IBlogCategoryDao dao = new BlogCategoryDao(factory);
IBlogCategoryService service = new BlogCategoryService(dao);

BlogCategory category = service.GetById(id);

try
{
    if (category != null)
    {
    service.Delete(category);
    worker.Commit();
    Console.WriteLine("Category deleted successfully!");
    }
    else
    {
    Console.WriteLine("Entity doesn't exist.");
    }
}
catch (Exception ex)
{
    Console.WriteLine("Error deleting category: {0}", ex.Message);
}

In my MVC 3 application I'm using the Ninject.MVC3 NuGet package, and this is in the RegisterServices method.

private static void RegisterServices(IKernel kernel)
{
    kernel.Bind<IDatabaseFactory>().To<DatabaseFactory>();
    kernel.Bind<IUnitOfWork>().To<UnitOfWork>().InRequestScope();

    kernel.Bind<IBlogCategoryDao>().To<BlogCategoryDao>();
    kernel.Bind<IBlogDao>().To<BlogDao>();

    kernel.Bind<IBlogCategoryService>().To<BlogCategoryService>();
    kernel.Bind<IBlogService>().To<BlogService>();
} 

While this works for the most part, Get requests, all POST requests (Insert, Update, Delete) don't get executed. There is no exception thrown and when I step through it, it goes through the SaveChanges() method without a problem and returns back up the stack, but nothing is executed. So I know I must be missing something with my Ninject configuration.

Here's my Unit of Work class.

public class UnitOfWork : IUnitOfWork
{
    private Database _database;  <-- DbContext derived class

    private readonly IDatabaseFactory _databaseFactory;

    public UnitOfWork(IDatabaseFactory databaseFactory)
    {
        this._databaseFactory = databaseFactory;
    }

    public Database Database
    {
        get
        {
            return _database ?? (_database = _databaseFactory.Get());
        }
    }

    public void Commit()
    {
        Database.Commit();
    }
}

Here's the DatabaseFactory class:

public class DatabaseFactory : Disposable, IDatabaseFactory
{
    private Database _database;

    public DatabaseFactory()
    {

    }

    public virtual Database Get()
    {
        if (_database == null)
        {
            _database = DataObjectFactory.CreateContext();
        }

        return _database;
    }

    protected override void DisposeCore()
    {
        if (_database != null)
        {
            _database.Dispose();
        }
    }
}

And my DataObjectFactory class:

public static class DataObjectFactory
{
    private static readonly string _connectionString;

    /// <summary>
    /// Static constructor. Reads the connectionstring from web.config just once.
    /// </summary>
    static DataObjectFactory()
    {
        string connectionStringName = ConfigurationManager.AppSettings.Get("ConnectionStringName");
        _connectionString = ConfigurationManager.ConnectionStrings[connectionStringName].ConnectionString;
    }

    /// <summary>
    /// Creates the Context using the current connectionstring.
    /// </summary>
    /// <remarks>
    /// Gof pattern: Factory method. 
    /// </remarks>
    /// <returns>Action Entities context.</returns>
    public static Database CreateContext()
    {
        return new Database(_connectionString);
    }
}

This is a similar pattern as used in the EFMVC CodePlex application, but I don't use AutoFac.

Any thoughts on this are appreciated.

Thanks.

Answer 1

I just do this:

kernel.Bind<IUnitOfWork>.To<EFUnitOfWork>().InRequestScope();

EFUnitOfWork.cs

public class EFUnitOfWork : DbContext, IUnitOfWork
{
    // your normal DbContext plus your IUnitOfWork members that delegate to EF context
}

Since EF already implements a form of Unit Of Work, this allows you to use a more generic interface for it, and inject it easily.

Also, you can implement the EF constructors for connection strings and just pass them to base constructors. Then you can use the Ninject .WithConstructorArgument() to configure the connection string using your AppSettings code.