Les deux mécanismes communs pour la création de liaisons d'injection de dépendance, telles que via un conteneur COI, proviennent d'une configuration XML ou d'un bloc de code impératif. Dans ces cas, la paire de valeurs de clé est explicite (i.e. clé = type demandé, valeur = type retourné).
Néanmoins, il existe une troisième approche "heuristique" où un conteneur d'application / CIO est donné uniquement des clés [imycyclasse] et le conteneur reflète ensuite sur un ensemble de dépendances de l'assemblage d'application pour trouver toutes les classes de béton appariées par nom [myClass]. Dit différemment, les valeurs "Type de retour" sont découvertes plutôt que déclarées.
Qu'est-ce que j'aimerais savoir est double:
4 Réponses :
J'ai généralement fait ce que vous décrivez comme une étape personnalisée dans la congiguration. AFAIK, il n'y a pas de conteneur à l'absence de la boîte, une telle stratégie (et à mon avis n'est pas une partie de conteneur, mais une truc de configuration qui devrait être externe de la responsabilité du conteneur).
Qu'est-ce que vous appelez une approche "Heuristic", c'est ce que j'appelle des conventions. La plupart des conteneurs COO vous permettent de remplacer la manière dont ils résolvent les liaisons, ce qui signifie que vous pouvez introduire toute convention que vous souhaitez. Il n'y a pas de telles conventions par défaut que je connais. Plutôt, la plupart des conteneurs ne font rien comme leur défaut; C'est votre travail de leur dire comment résoudre les types, via un fichier de configuration ou via le code.
Un exemple de convention personnalisée que je trouve est plutôt courant qui vous permet de gagner beaucoup de déclarations: si le type demandé est un type d'interface commençant par "I" et terminé par "Service" puis tente de créer et de résoudre un type avec le même nom à part le "i". Cela résoudra les noms tels que Puisque vous pouvez remplacer la manière dont la plupart des conteneurs de COO se lient, vous pouvez également introduire d'autres comportements. Généralement, cependant, il y a vraiment deux options:
ifooservice à fooservice automatiquement. De plus, vous pouvez introduire la logique pour choisir des services différents dans différents contextes, et vous pouvez gérer la durée de vie des instances de service dans un lieu commun.
Depuis que j'ai utilisé Structuremap Je saurais un peu comment faire une telle chose avec ce conteneur: il s'agirait essentiellement d'une convention d'inscription personnalisée (d'initialisation ou d'un registre, entrez dans Le bloc Scan-Lambda et trouvez la méthode «Convention»).
Il vous permet de regarder les types réfléchis, puis de les insérer dans la configuration du conteneur à votre guise. Cela devrait permettre ce que vous essayez de faire.
Ceci s'appelle Les mécanismes de configuration les plus courants utilisés pour les conteneurs di sont
une quatrième, mais une approche rare, consiste à utiliser des attributs. Cadre d'extensibilité géré est l'exemple le plus important de cette approche, ce qui est plus commun dans Java.
Unity et Ninject soutiennent également la configuration basée sur la Convention (de même que la plupart des autres conteneurs de la COI d'éminents).
Unity 2.0 ne prend pas en charge la configuration basée sur la Convention. Lorsque j'ai écrit mon livre, j'ai correspondu avec Chris Tavares (l'architecte de l'unité), qui a confirmé qu'il ne supporte pas l'enregistrement automatique.
Vous avez raison à propos de l'unité 2.0 n'ayant pas d'immédiat hors de la boîte de support, mais vous pouvez plutôt utiliser facilement une approche basée sur la convention en utilisant E.G. iunityContainer.registerType , donc il peut (facilement) être fait. En fait, c'est ce que nous faisons dans l'un de nos projets actuels.