Comment cacher la vraie bibliothèque de conteneurs IoC?

Question

Je veux isoler tout mon code de la bibliothèque de conteneurs IoC que j'ai choisie (Unity). Pour ce faire, j'ai créé une interface IContainer qui expose Register() et Resolve(). J'ai créé une classe appelée UnityContainerAdapter qui implémente IContainer et qui enveloppe le vrai conteneur. Ainsi, seul l'assembly où UnityContainerAdapter est défini connaît la bibliothèque Unity.

J'ai une fuite dans ma pensée d'isolement. Unity recherche des attributs sur les membres d'un type pour savoir où injecter les dépendances. La plupart des bibliothèques de l'IoC que j'ai vues soutiennent également cela. Le problème que j'ai est que je veux utiliser cette fonctionnalité mais je ne veux pas que mes classes aient une dépendance sur l'attribut spécifique d'Unity.

Avez-vous des suggestions sur la façon de résoudre ce problème?

Idéalement, je créerais mon propre attribut [Dependency] et l'utiliserais dans mon code. Mais je devrais dire au vrai conteneur la recherche de mon attribut au lieu du sien.

Answer 1

J'ai trouvé la réponse: Unity utilise une extension pour configurer ce qu'il appelle des «politiques de sélection». Pour remplacer les attributs utilisés par Unity, il vous suffit de coder votre propre version de la classe UnityDefaultStrategiesExtension et d'enregistrer vos propres "stratégies de sélecteur" qui utilisent vos propres attributs.

Voir this post sur le site codé Unity pour plus de détails sur la façon de procéder.

Je ne suis pas sûr que ça va être facile de faire la même chose si je passe à une autre bibliothèque IoC mais cela résout mon problème pour le moment.

Answer 2

Vérifiez le projet Common Service Locator:

La bibliothèque de services communs Locator contient une interface commune pour emplacement de service qui application et développeurs cadre peuvent faire référence. La bibliothèque fournit une abstraction sur des conteneurs IoC et des localisateurs de service . L'utilisation de la bibliothèque permet à une application d'accéder indirectement aux capacités sans se fier aux références . L'espoir est qu'en utilisant cette bibliothèque, les applications tierces et les cadres peuvent commencer à exploiter IoC/Service Location sans attacher eux-mêmes à une implémentation spécifique .

---

Edit: Cela ne semble pas résoudre votre désir d'utiliser la déclaration basée sur les attributs d'injection de dépendance. Vous pouvez soit choisir de ne pas l'utiliser, soit trouver un moyen de résumer les attributs à plusieurs bibliothèques d'injection (comme vous l'avez mentionné).

C'est le problème de base avec les interfaces déclaratives - elles sont liées à une implémentation particulière. Personnellement, je m'en tiens à l'injection de constructeur, donc je ne rencontre pas ce problème.

Answer 3

Vous ne pouviez pas configurer votre configuration sans les attributs, en XML. Cela le rend un peu plus "flou" je sais, personnellement, j'utilise une combinaison de xml et d'attributs, mais au moins cela "résout" votre dépendance à l'égard de l'unité.