Come posso ottenere che Ninject 2 usi il costruttore senza parametri per LINQ su 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 a 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). Ciascuno di questi repository necessita di un'istanza di DataContext da LINQ a SQL per comunicare con il database, in modo tale che sia un parametro costruttore nelle classi concreta di repository. 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à della filosofia del lavoro, mi sembra logico crearne uno per HttpRequest.

Io di solito utilizzo il costruttore senza parametri per MyDataContext: non lo vedo come un rischio perché viene utilizzato per un progetto interno su un sistema di test, quindi la stringa di connessione "incorporata" nel datacontext è innocua. Tuttavia, dato che Ninject 2 è "avido" e vuole il costruttore con i parametri MOST, e non posso davvero attaccare il parametro [Inject] nel codice generato in alcun modo significativo, ottengo un errore ogni volta che Ninject tenta di creare uno dei miei controller (che ha bisogno di un repository, che ha bisogno del datacontext).

Ho visto menzionare IConstructorScorer e la possibilità di creare uno "invertito" che userebbe sempre il costruttore con i parametri LEAST, ma poi di nuovo, questo cambierebbe il modo in cui l'iniezione funziona per tutto il resto - il comportamento predefinito è probabilmente quello che voglio per tutto tranne il datacontext.

Quindi, c'è un modo semplice e pulito per specificare che questa associazione (e solo questa associazione) deve utilizzare un costruttore specifico? Possiamo fare la stessa cosa con i provider di Ninject 1 e forse fornire la nostra "fabbrica"? O dovrei semplicemente arrendermi e provare a inserire parametri nel datacontext che ha senso?

Answer 1

Capito - è abbastanza facile da legare ad un fornitore;

Ninject chiamerà il mio ContextProvider ogni volta che è necessario creare uno di questi fastidiosi oggetti DataContext. Ecco come appare la classe del mio fornitore:

public class ContextProvider : IProvider 
{ 
    #region IProvider Members 

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

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

    #endregion 
} 

Sembra che ci sia riuscito, funziona perfettamente. :)

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())