Puis-je utiliser un conteneur IoC pour créer une dépendance qui nécessite une valeur d'exécution?

Question

Je suis un débutant IoC, donc je me demande si c'est même le bon outil pour le travail que je veux faire. J'écris une application multi-tenant, et il y a plusieurs endroits où nous pourrions vouloir utiliser différentes implémentations d'interfaces basées sur l'organisation à laquelle appartient l'utilisateur actuellement connecté. Par exemple, si un utilisateur d'une organisation crée un bon de travail, le superviseur de cet utilisateur doit recevoir un e-mail. Mais pour toutes les autres organisations, cet e-mail n'a pas besoin d'être envoyé. Modèle de stratégie classique genre de chose.

Ma question est, puis-je demander en quelque sorte le conteneur IoC de regarder une certaine valeur d'exécution (le OrganizationId de l'utilisateur connecté dans ce cas) pour déterminer quelle mise en œuvre du IWorkOrderProcessor à injecter dans le constructeur de l'objet en a besoin? J'utilise actuellement Windsor, mais des exemples utilisant d'autres conteneurs seraient acceptables.

Answer 1

Windsor a un point d'extension qui est un ajustement parfait pour les applications multi-locataires: IHandlerSelector.

• http://ayende.com/Blog/archive/2008/10/05/windsor-ihandlerselector.aspx
• http://mikehadlow.blogspot.com/2008/11/multi-tenancy-part-2-components-and.html

Cela vous permet de coder votre application comme si elle n'a pas été multi-locataire. La logique de multi-location est déplacée sur de votre logique métier.

Answer 2

La plupart des bons conteneurs IOC supporteront ce type d'utilisation. Je ne connais pas Windsor, mon CIO de choix est StructureMap. Dans l'interface StructureMap fluent, vous disposez de nombreuses options pour configurer les paramètres d'exécution des objets injectés en fonction de tout ce que vous pouvez exprimer dans le code. Je suis sûr que Windsor offre la même chose. La seule chose que je dis à propos de l'utilisation d'IOC comme ceci est que cela rendrait parfois une solution plus difficile à comprendre. Dans votre exemple, si vous avez vraiment un vrai cas d'utilisation pour le modèle de stratégie où vous implémenteriez ce comportement même si vous n'utilisiez pas IOC comme objet de stratégie injecté (en utilisant une approche Factory) alors je dirais, oui, aller de l'avant avec la mise en œuvre du CIO. Mais si vous n'avez pas vraiment besoin d'injecter toute une abstraction d'objet pour exprimer la logique de savoir si certains utilisateurs reçoivent des courriels, alors peut-être que ce serait un cas de modèles pour des motifs.

Answer 3

Je pense que vous pouvez, parce que conteneur IoC peut utiliser différents types d'injection:

1. une injection de constructeur,
2. injection setter,
3. une injection d'interface (injection de méthode)

L'injection du constructeur donne l'objet entièrement initialisé, mais les types et les valeurs que vous injectez doivent être connus juste avant la création de l'objet (par exemple, ils peuvent être chargés depuis la configuration f ile).

L'injection de méthode (ou de réglage) est flexible - Vous pouvez retarder l'injection jusqu'à l'obtention du type ou de la valeur désirée. Inconvénient de cette approche est que vous n'avez pas entièrement l'objet initialisé lorsque vous le créez. Tout dépend de la façon dont votre conteneur est implémenté.

Par ailleurs: a posé des questions similaires: IoC: Existing runtime objects rather than container-initialised prerequisites for components

Answer 4

Ceci est un défi commun avec DI, et la réponse est toujours de créer et d'injecter un Abstract Factory. Dans votre cas, vous pouvez définir une interface comme ceci:

public interface IWorkerProcessorFactory 
{ 
    IWorkerProcessor Create(int organizationId); 
} 

Dans toutes les classes où vous avez une carte d'identité de l'organisation et ont besoin d'une instance de IWorkerProcessor, vous prenez une dépendance à l'égard IWorkerProcessorFactory et invoquez sa méthode Create.

Ce modèle fonctionne avec DI Poor Man ou à peu près n'importe quel conteneur DI que vous souhaitez utiliser.

Voici un exemple plus complet: Can't combine Factory/DI