Comment puis-je faire en sorte que Ninject 2 utilise un constructeur sans paramètre pour LINQ to SQL DataContext?

Question

J'ai commencé à utiliser Ninject 2 (téléchargés à partir Github hier, y compris le projet d'extension MVC) avec un projet basé sur les technologies suivantes:

• .Net 3.5 SP1
• ASP.NET MVC 1.0
• LINQ à rien de magique ici SQL

- J'ai quelques interfaces de dépôt (nommés comme IEntityRepository) qui sont implémentés en utilisant LINQ to SQL dans le code d'exécution (et en utilisant un Hashtable dans le code de test unitaire). Chacun de ces dépôts a besoin d'une instance de DataContext de LINQ à SQL afin de parler à la base de données, c'est donc un paramètre constructeur sur les classes de référentiel concret. La liaison est configuré comme ceci:

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

La raison est que je veux être en mesure de partager des entités entre les différents référentiels si je devais arriver à besoin de plus d'entre eux, et avec l'LINQ à SQL unité datacontext de la philosophie du travail, il me semble logique de créer un par HttpRequest. J'utilise généralement le constructeur sans paramètre pour MyDataContext - Je ne vois pas cela comme un risque car cela est utilisé pour un projet interne sur un système de test, donc la chaîne de connexion "intégrée" dans le datacontext est inoffensive. Cependant, puisque Ninject 2 est "gourmand" et veut le constructeur avec les paramètres MOST, et je ne peux pas vraiment coller le paramètre [Inject] dans le code généré de manière significative, j'obtiens une erreur chaque fois que Ninject essaie de créer un de mes contrôleurs (qui a besoin d'un référentiel, qui a besoin du datacontext).

J'ai vu la mention IConstructorScorer et la possibilité d'en faire une "inversée" qui utiliserait toujours le constructeur avec les paramètres LEAST, mais là encore, cela changerait le fonctionnement de l'injection pour tout le reste - le comportement par défaut est probablement ce que je veux pour tout sauf le datacontext. Donc, y a-t-il un bon moyen de spécifier que cette liaison (et seulement cette liaison) devrait utiliser un constructeur spécifique? Pouvons-nous faire la même chose avec les fournisseurs que dans Ninject 1, et peut-être fournir notre propre "usine"? Ou devrais-je simplement céder et essayer d'introduire des paramètres dans le contexte de données qui ont du sens?

Answer 1

Compris: il est assez facile de se lier à un fournisseur; Ninject va maintenant appeler mon ContextProvider chaque fois qu'il a besoin de construire un de ces objets DataContext embêtants. Voici à quoi ressemble la classe de mon fournisseur:

public class ContextProvider : IProvider 
{ 
    #region IProvider Members 

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

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

    #endregion 
} 

On dirait que je m'en sors - ça marche bien. :)

Answer 2

Je suppose que vous pouvez également utiliser « ToMethod » contraignant pour éviter la mise en œuvre fournisseur personnalisé, voilà comment je l'utilise que:

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