J'ai l'architecture suivante où une classe de service publique référençant une classe d'aide interne existe dans une autre assemblée :
ApplicationAssembly {
public class Widget {
public Widget(ReferencedAssembly.Service service) { ... }
}
}
ReferencedAssembly {
public class Service {
public Service(Helper helper) { ... }
}
class Helper { ... }
}
(Je réalise que je ne peux pas mettre une classe interne dans les arguments du constructeur d'une classe publique - j'essaie juste d'illustrer le modèle IoC que je poursuis).
Le problème est que ApplicationAssembly
ne peut pas voir ReferencedAssembly.Helper
Il ne peut donc pas être enregistré dans mon conteneur IoC (Autofac dans ce cas). Le résultat est le suivant Helper
ne peut être résolu lorsque j'essaie de résoudre Service
. Quelle est ma meilleure option ?
-
Option 1 : supprimer
Helper
deService
et le remplacer dans le constructeur de manière explicite. Je n'aime pas cette option parce qu'elle brise en quelque sorte le paradigme IoC. -
Option 2 : Faire
Helper
mettre en œuvre uneIHelper
puis ajoutez un module public dans l'interfaceReferencedAssembly
qui enregistreHelper
comme unIHelper
. Je n'aime pas cette option car elle nécessiteApplicationAssembly
de connaître trop de détails d'implémentation surService
et si l'utilisateur oublie d'enregistrer ce module au démarrage, tout se casse la figure. -
Option 3 : Créer un constructeur statique public sur
Service
qui construit un 2ème conteneur IoC spécifiquement pourReferencedAssembly
et registresHelper
en elle. RetirezHelper
deService
et le résoudre dans le constructeur à l'aide du deuxième conteneur IoC. Cette option semble être la meilleure, mais elle nécessite plus de code de "plomberie" que les autres. Je ne suis pas non plus un grand fan des constructeurs statiques publics. -
Option 4. Changer mon architecture pour quelque chose de tout à fait différent.