2016-11-30 1 views
0

Dans mon application, je peux enregistrer différentes sources de données par leur nom. Ces sources de données ont chacune quelques propriétés string requises, ainsi qu'un ensemble d'autres dépendances, mais sont par ailleurs identiques, donc prenez quelques implémentations standard différentes.Fournisseurs Ninject: quelle est la bonne façon de résoudre les dépendances

Pour créer des instances de chaque source de données à la demande, je crée une liaison à une instance d'un Provider<T> qui est initialisée avec les informations requises pour accéder à cette source de données. Le fournisseur ressemble à quelque chose comme ci-dessous:

public class StandardListProvider<T> : Provider<IListExecutor<T>> 
    where T : new() 
{ 
    public string Name  { get; set; } 
    public string ListMethod { get; set; } 

    public StandardListProvider(string name, string listMethod) 
    { 
     Name  = name; 
     ListMethod = listMethod; 
    } 

    protected override IListExecutor<T> CreateInstance(IContext context) 
    { 
     var connector = (IInternalConnector)context.Kernel.GetService(typeof(IInternalConnector)); 
     return new StandardListExecutor<T>(connector, Name) 
     { 
      ListMethodName = ListMethod 
     }; 
    } 
} 

Le problème est à résoudre les dépendances du StandardListExecutor<T> comme IInternalConnector. Évidemment je peux les construire manuellement, ou les demander de context.Kernel comme je suis dans mon exemple (et suggéré par Ninject Providers -> Get another dependency inside the provider), mais ceci aboutit à une requête sans information de Cible, ce qui n'est pas idéal si nous voulons effectuer des liaisons contextuelles pour les dépendances de StandardListExecutor.

J'ai essayé de jouer avec context.Request.CreateChild(...), mais cela semble nécessiter une réflexion à chaque activation pour créer un ParameterTarget. Il ne semble pas y avoir beaucoup d'informations à ce sujet dans les documents Ninject non plus.

Ma question est: Quelle est la bonne façon de résoudre/demander des dépendances, ou d'autres services comme celui-ci dans le processus d'activation d'une liaison existante?

Modifier

Les demandes se font via les branchements Ninject.Mvc dans le processus d'activation du contrôleur System.Web.Mvc.

+0

Ce qui manque à votre question, c'est comment les objets fournis sont réellement "demandés". Par conséquent, je ne vois pas vraiment le besoin d'un fournisseur ici. Pourquoi ne pas simplement créer une liaison à la place? Vous pouvez ajouter des arguments constructeur à la liaison. Une meilleure pratique pourrait être de créer un type 'FooParameters' ou' FooSettings' pour chaque exécuteur. – BatteryBackupUnit

+0

Salut @BatteryBackupUnit - les requêtes réelles sont effectuées via les connexions Ninject.Mvc dans le processus d'activation du contrôleur. L'idée de créer une liaison pour gérer tout cela honnêtement ne m'était pas venue à l'esprit, et je n'avais pas non plus créé d'objet de paramétrage pour chaque type d'exécuteur. Je voulais vraiment obtenir autant de logique d'activation que possible ** out ** de la liaison car les liaisons elles-mêmes sont créées par un 'IMissingBindingResolver'. En tout cas, la question de ma question concerne la meilleure façon de créer des «fournisseurs» personnalisés, car cette question m'est venue à l'esprit sur quelques projets différents. – s3raph86

Répondre

0

Vous devriez pouvoir utiliser l'extension Ninject.Extensions.ContextPreservation. Plus précisément, la méthode d'extension IContext.ContextPreservingGet(...):

var connector = context.ContextPreservingGet<IInternalConnector>(); 

Cependant, personnellement, je pense que la création de types de paramètres spécifiques est le meilleur choix - car il est l'idée plus simple.

+0

Exactement ce que j'étais après - merci! – s3raph86