How can I get Ninject 2 to use parameterless constructor for LINQ to SQL DataContext?

Question

I have started using Ninject 2 (downloaded from Github yesterday including the MVC extension project) with a project based on the following technologies:

• .Net 3.5 Sp1
• ASP.NET MVC 1.0
• LINQ to SQL

Nothing magical here - I have a few repository interfaces (named like IEntityRepository) that are implemented using LINQ to SQL in the runtime code (and using a hashtable in the unit test code). Each of these repositories need an instance of the DataContext from LINQ to SQL in order to talk to the database, so that is a constructor parameter on the concrete repository classes. The binding is set up like this:

Kernel.Bind<MyDataContext>().ToSelf().InRequestScope();

The reason for this is that I want to be able to share entities between different repositories if I should happen to need more of them, and with the LINQ to SQL datacontext unit of work philosophy, it seems to make sense to me to create one per HttpRequest.

I usually use the parameterless constructor for MyDataContext - I don't see that as a risk because this is used for an internal project on a test system, so the "built-in" connection string in the datacontext is harmless. However, since Ninject 2 is "greedy" and wants the constructor with the MOST parameters, and I can't really stick the [Inject] parameter into generated code in any meaningful way, I get an error whenever Ninject tries to create one of my controllers (which needs a repository, which needs the datacontext).

I have seen mention of IConstructorScorer and the ability to make an "inverted" one that would always use the constructor with the LEAST parameters, but then again, this would change how injection works for everything else - the default behavior is probably what I want for everything but the datacontext.

So - is there a nice, clean way to specify that this binding (and only this binding) should use a specific constructor? Can we do the same thing with providers as in Ninject 1, and perhaps supply our own "factory"? Or should I just give in and try to feed parameters into the datacontext that make sense?

Answer 1

I guess you could also use 'ToMethod' binding to avoid implementing custom provider, that's how I use that:

Kernel.Bind<MyDataConext>().ToMethod(c => new MyDataContext())

Answer 2

Figured it out - it is quite easily done by binding to a provider;

Kernel.Bind<MyDataContext>().ToProvider<ContextProvider>().InRequestScope();

Ninject will now call my ContextProvider whenever it needs to build one of those pesky DataContext objects. This is what my provider class looks like:

public class ContextProvider : IProvider
{
    #region IProvider Members

    public object Create(IContext context)
    {
        return new MyDataContext();
    }

    public Type Type
    {
        get { throw new NotImplementedException(); }
    }

    #endregion
}

Seems like I got away with it - it works fine. :)