Come posso ottenere Ninject 2 per usare costruttore senza parametri per LINQ to SQL DataContext?

Question

Ho iniziato a utilizzare Ninject 2 (scaricato da Github ieri tra cui il progetto di ampliamento MVC) con un progetto basato sulle seguenti tecnologie:

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

nulla di magico qui - Ho un paio di interfacce repository (chiamati come IEntityRepository) che vengono implementati utilizzando LINQ to SQL nel codice runtime (e utilizzando una tabella hash nel codice di unit test). Ognuno di questi depositi hanno bisogno di un'istanza del DataContext da LINQ to SQL per comunicare con il database, in modo che è un parametro del costruttore sulle classi repository di cemento. Il legame è impostato in questo modo:

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

La ragione di questo è che voglio essere in grado di condividere le entità tra i diversi repository se mi capitasse di avere bisogno di più di loro, e con il LINQ to SQL DataContext unità di filosofia di lavoro, sembra avere un senso per me creare uno per HttpRequest.

Io di solito uso il costruttore senza parametri per MyDataContext - non vedo che come un rischio, perché questo viene utilizzato per un progetto interno su un sistema di test, quindi la stringa di connessione "built-in" nel DataContext è innocuo. Tuttavia, dal momento che Ninject 2 è "greedy" e vuole il costruttore con i parametri più, e non posso davvero attaccare il parametro [Inject] nel codice generato in modo significativo, ottengo un errore ogni volta che Ninject cerca di creare uno dei miei controllori ( che ha bisogno di un repository, che ha bisogno il DataContext).

Ho visto menzione di IConstructorScorer e la capacità di fare un one "rovesciata", che sarebbe sempre utilizzare il costruttore con i parametri meno importante, ma poi di nuovo, questo cambierebbe come funziona l'iniezione per tutto il resto - il comportamento predefinito è probabilmente ciò che voglio che per tutto, ma il DataContext.

- c'è un modo bello e pulito per specificare che questo legame (e solo questo legame) dovrebbe utilizzare un costruttore specifico? Possiamo fare la stessa cosa con i fornitori come in Ninject 1, e forse fornire la nostra propria "fabbrica"? O devo solo dare e cercare di alimentare i parametri nel DataContext che senso?

Answer 1

capito - è abbastanza facilmente fatto legandosi a un provider;

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

Ninject ora chiamare il mio ContextProvider ogni volta che ha bisogno di costruire uno di quegli oggetti DataContext fastidiosi. Questo è ciò che la mia classe fornitore appare come:

public class ContextProvider : IProvider
{
    #region IProvider Members

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

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

    #endregion
}

Sembra come ho ottenuto via con esso - funziona benissimo. :)

Answer 2

Credo che si potrebbe anche usare 'ToMethod' vincolante per evitare di attuare provider personalizzato, è così che io uso che:

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