Injection de dépendance dans une application à plusieurs niveaux?

Question

J'ai une application de service .NET à 3 niveaux, qui suit l'approche standard:

Frontend -> Object Model / Business Logic -> Data Access

J’essaie d’apprendre sur l’injection de dépendance en cours de route, et j’ai jusqu’à présent trouvé cela génial (avec Autofac). Chacun des 3 niveaux doit créer un assortiment d'objets, parfois avec une configuration supplémentaire / etc. Il semble que le conteneur d’ID devrait être l’idéal pour résoudre ce problème, mais j’ai quelques problèmes pour savoir où il devrait vivre par rapport au reste du système.

Actuellement, j'ai une classe dans le frontal qui configure le conteneur DI. En gros, il s’agit d’un gros code énonçant container.Register<SomeType>() et ainsi de suite.

Le problème est qu’il configure le conteneur pour les 3 niveaux et doit donc avoir une connaissance assez invasive de la couche d’accès aux données. Avoir du code dans mon interface avec de telles connaissances déclenche des alarmes dans mon esprit car le but de séparer l'application en plusieurs niveaux est d'éviter cette situation exacte.
Cela est également aggravé par le fait que ma couche d'accès aux données n'est pas simplement un serveur SQL, mais qu'elle est constituée de nombreux appels complexes d'interopérabilité COM et de P / Invoke, ce qui a donc un impact considérable sur le DI. configuration.

J'ai envisagé de le dissocier - par exemple, un conteneur par niveau ou un & "Setup &"; classe dans chaque niveau qui communique avec le conteneur DI global pour enregistrer ses propres bits, mais je ne suis pas sûr que cela entraînera plus de problèmes que cela ne résoudra ...

J'apprécierais vraiment que quiconque puisse partager ses expériences d'utilisation de DI avec des applications à plusieurs niveaux.

Merci, Orion.

Answer 1

Cela dépend si vous avez trois niveaux (séparation physique) ou si toutes vos couches logiques sont déployées ensemble. Si le client est séparé de votre BL et communique via un service Web ou une WCF, le client et le serveur ont besoin de leurs propres conteneurs car ils s'exécutent dans des processus ou des machines distincts. Les conteneurs n'enregistreraient que leurs propres composants et les interfaces de la couche "suivante".

D'un autre côté, si toutes les couches s'exécutent dans le même processus, vous ne devriez avoir qu'un seul conteneur. Le conteneur serait initialisé et hébergé au point de départ de l'application, tel que global.asax pour une application Web.

Le problème lié au fait que l'hôte de conteneur connaissait une bonne partie des différentes parties du système pourrait être résolu en n'enregistrant pas les classes une par une, mais en enregistrant tous les types dans un assemblage. De cette manière, vous n'avez pas besoin de références fortes à tous les assemblys de votre solution, mais uniquement pour configurer le conteneur. Exemple illustrant comment cela peut être réalisé avec Castle Winsdor:

Kernel.Register(AllTypes.Pick().FromAssemblyName("DataAccessLayer.dll"));
Kernel.Register(AllTypes.Pick().FromAssemblyName("BusinessLogic.dll"));