Ne pas comprendre où créer IoC conteneurs dans l'architecture du système

Question

Dire que j'ai les 4 .net ensembles suivants:

1. Winforms UI
2. affaires Logic
3. SQL Server Data Access (mise en œuvre d'un IRepository)
4. Interfaces communes (définition d'IRepository, etc.)

Ma logique métier (2) effectue des appels à la couche d'accès aux données (3) via IRepository (défini en 4) en utilisant l'injection de dépendance du constructeur. Cependant, lorsque je crée un objet métier, je dois passer dans un dépôt réel. Je le fais en ayant une classe singleton dans ma couche de logique métier retourne l'objet concret en cours d'implémentation implémentant IRepository. J'en arrive à la conclusion que c'est une mauvaise chose, car ma couche logique métier doit maintenant faire référence à 3 et 4.

Je pense que j'ai besoin d'un conteneur IoC mais la question est de savoir où je le crée/le place comme il semble que partout où je crée cela (1 - UI)? devra également contenir une référence à 3 (SQL Server Data Access). Ne suis-je pas en train de déplacer le problème plutôt que de réaliser le découplage réel? Est-ce que je crée le conteneur IoC dans l'interface utilisateur? Ou exposer à travers un autre nouvel assemblage.

(je suis en utilisant C#, .Net 3.5 et AutoFac)

Merci.

Answer 1

conteneur IoC devraient généralement être créés dans le projet hôte (point d'entrée de l'application). Pour l'application Windows.Forms, c'est le projet exe.

Généralement dans des solutions simples (moins de 10 projets), seul un projet hôte doit avoir une référence à la bibliothèque IoC.

PS: Structuring .NET Applications with Autofac IoC

Answer 2

La distinction de module et les "étendues" définies par les modules existent principalement au moment de la compilation. Au moment de l'exécution, c'est un gros désordre;) Ceci est utilisé par la plupart des conteneurs d'IOC et ils ne se soucient pas vraiment de l'endroit où ils se trouvent. Le conteneur IoC d'une application Web est généralement créé au niveau le plus éloigné (très proche du conteneur Web lui-même).

Answer 3

Il est vrai que vous pouvez le créer n'importe où, mais j'introduirais un calque supplémentaire, appelons-le 3.5.

Votre 3 actuel serait où votre IoC réside pour l'accès aux données - cela deviendrait un emballage pour votre DAL réel. Basé sur votre config, 3 créerait soit un référentiel simulacre ou un référentiel concret. Donc, 2 fait toujours référence à 3, mais c'est juste une interface avec la couche DAL réelle qui est configurée via votre infrastructure IoC.

Sinon, vous pouvez rouler votre propre el-cheapo 'IoC - changer votre Big truand Singleton à une passerelle statique - Abstracting IoC Container Behind a Singleton - Doing it wrong?

Answer 4

Lors de l'enregistrement des composants, il existe plusieurs possibilités:

1. Inscription en Code:

   • directement
     problème: vous devez faire référence à tout (vous êtes ici)
   • indirectement
     Problème: pour savoir ce qui doit être enregistré
     Solution:
     1. utiliser des attributs
     interface marqueur
     2. utilisation comme IService
     3. conventions d'utilisation (voir StructureMap)

2. Enregistrement avec fichier de configuration:

   • laisser le conteneur tout faire
   • lire le fichier vous

Answer 5

niveau supérieur est un moyen d'aller (IU, comme Rinat dit). Maintenant, en ce qui concerne les références, la manière la plus simple est simplement de passer en revue tous les assemblages dans le dossier actuel et d'utiliser une convention pour obtenir les services. Les attributs fonctionnent bien, mettre des classes de registrar dans chaque assemblage fonctionne bien, tout ce qui vous convient. Le code pour extraire tout devrait probablement être dans un assembly séparé, à moins que votre framework IoC ne le fasse déjà.