Comment gérez-vous la configuration avec l'injection de dépendance?

Je suis un grand fan de DI / IOC. Il est idéal pour gérer / résumer les dépendances matérielles et simplifie un peu la vie.

Cependant, j'ai un petit problème avec cela, que je ne sais pas comment résoudre.

L'idée de base dans DI / IOC est que lorsqu'un objet est instancié, toutes ses dépendances sont pré-remplies dans le constructeur.

Cependant à mon humble avis, il existe plusieurs types de paramètres pour les constructeurs (en particulier lorsque vos objets sont immuables).

Dépendances (objets requis pour que votre objet fonctionne)
Configuration (informations sur l'environnement requis pour travailler)
Paramètres (données sur lesquelles le travail est effectué)

Je trouve qu'IOC fonctionne bien avec les dépendances. Mais j'essaie toujours de trouver la meilleure façon de gérer les deux autres. Cependant, comme le constructeur est exécuté pour être exécuté par le conteneur IOC, il semble que je doive placer ces éléments dans le conteneur IOC.

J'aimerais savoir quelles stratégies / modèles les gens utilisent et quels avantages et inconvénients les gens ont trouvés.

NB. Je suis conscient que c'est une question hautement subjective et j'ai essayé d'en faire une "bonne" question subjective selon les directives SE.

design-patterns configuration-management inversion-of-control

— ArTs
source

Par «Configuration», voulez-vous dire la configuration de l'environnement de développement (comme le développement ou la production)? Si c'est le cas, je gère généralement cela comme une dépendance traditionnelle.

— MetaFight

Mieux vaut construire avec des dépendances mais une configuration par défaut pour que l'objet soit bien formé. Appelez des méthodes supplémentaires pour définir la configuration et d'autres paramètres. Faire trop dans le ctor est une mauvaise chose.

— david.pfx

I am still trying to work out the best way to deal with the other two- Les transmettre comme paramètres ordinaires à votre objet?

— Robert Harvey

@RobertHarvey objets immuables? Ils facilitent le débogage.

— ArT

Réponses:

Configuration (informations sur l'environnement requis pour travailler)

Créez une classe de configuration (pour être pointilleux: une interface + une implémentation) dont le but est de fournir les informations sur l'environnement. Cela rend la configuration en rien différente des autres objets requis pour que votre objet fonctionne (point 1).

Paramètres (données sur lesquelles le travail est effectué)

Dans un environnement orienté objet, les types de données primitifs peuvent être encapsulés dans des objets, ce qui conduit également au point 1. Mais vous trouverez probablement cette question SO intéressante, elle traite exactement de la situation des paramètres primitifs dans un constructeur, lors de l'utilisation d'un DI récipient. Dans l'exemple donné, la conception pourrait être améliorée, ce qui évitait complètement le besoin de types primitifs dans le constructeur.

— Doc Brown
source

Ce que je fais est un modèle d'usine pour ces cas.

Je n'utilise pas l'objet lui-même comme dépendance mais crée un objet d'usine avec une méthode Get qui accepte des paramètres qui ne peuvent pas être liés automatiquement par le conteneur.

Ex.:

 interface IDependencyObject {
       ....
 }

 class DependencyObject {

      public DependencyObject(int primitive, IAnotherDependency anotherDependency) {
      ...
      }

 }

 class DependencyObjectFactory {

      private readonly IAnotherDependency anotherDependency;

      public DependencyObjectFactory(IAnotherDependency anotherDependency) {
           this.anotherDependency = anotherDependency;
      }

      public IDependencyObject Get(int primitive) {
           return new DependencyObject(primitive, anotherDependency);
      }
 }

 interface IDependencyObjectFactory {
       IDependencyObject Get(int primitive);
 }

— Vilém Procházka
source