J'essaie de décider s'il est logique de suivre ou non l'effort supplémentaire pour encapsuler mon conteneur IOC. L'expérience me dit que je devrais mettre une couche d'encapsulation entre mes applications et tout composant tiers. Je ne sais tout simplement pas si cela est limitrophe sur la surkill.
Je peux penser à des situations où je pourrais vouloir changer de contenants. Par exemple, mon conteneur actuel cesse d'être maintenu, ou un conteneur différent est prouvé être plus léger / performant et mieux convient à mes besoins. Si cela se produit, alors je vais potentiellement avoir beaucoup de ré-câblage à faire.
Pour être clair, j'envisage de l'encapsulation de la résolution et des types. Je pense que c'est un no-évidence d'encapsuler la résolution - j'espère que c'est une pratique courante d'avoir une classe d'assistant / util déléguant au conteneur.
EDIT:
L'hypothèse est que je préfère faire filer mes types de manière programmatique pour la sécurité, la vérification et la refactorabilité du temps de compilation. C'est ce code et sa dépendance sur le conteneur que je cherche à me protéger.
J'ai également utilisé un conteneur de CIO pour plusieurs autres projets qui partagent une grande partie des mêmes relations, mais le conteneur est une douleur à travailler avec donc je veux changer. Mais, un changement signifie que je perds la réutilisabilité du code d'enregistrement. Par conséquent, pourquoi je contemplerais l'encapsulation. Ce n'est pas un énorme fardeau, mais celui que je voudrais néanmoins atténuer.
Je cherche à:
Je me rends compte que cela est un peu subjectif, alors les avantages / inconvénients peuvent être utiles
Merci!
4 Réponses :
Ouais va pour ça. Ce n'est pas beaucoup d'effort supplémentaire et comme vous dites, cela vous donne un meilleur isolement des composants tiers.
Cela signifie également que vous pouvez facilement éteindre le conteneur de la COI si vous trouvez quelque chose qui est mieux. Je l'ai récemment fait avec un échange de conteneur Spring.Net COI pour StructureMap.
Le ASP.NET MVC PLAD Le projet sur CodePlex est un bon endroit pour commencer. C'est ce que j'ai basé sur ma mise en œuvre.
le faire plus tard et seulement si vous avez la nécessité de changer de conteneurs de la COI.
Choisissez un conteneur IOC non invasif. C'est-à-dire que l'un où les objets étant liés à l'autre n'ont aucune dépendance sur le conteneur de la COI. Dans ce cas, il n'y a rien à encapsuler.
Si vous devez choisir un conteneur de COI nécessitant une dépendance sur le conteneur, choisissez-en une avec les dépendances / API les plus simples que vous pouvez. Si vous devez remplacer ce conteneur IOC (et que vous ne le ferez probablement pas), implémentez des adaptateurs qui comblent la nouvelle API à l'ancienne.
En d'autres termes, laissez le premier conteneur de COI soit celui qui définit les interfaces pour tout récipient futur afin de ne pas avoir à inventer le vôtre, et vous pouvez retarder l'une de ces sortes. de travail jusqu'à ce que vous en ayez absolument besoin.
EDIT:
Je ne vois pas un moyen de garantir la sécurité des types de la sécurité des types:
La résolution de type est généralement non invasive, par nature; C'est l'enregistrement qui nécessite généralement beaucoup de code spécifique au conteneur. C'est ce code (en supposant que je préfère la sécurité de type sur la configuration XML) que j'essaie de me protéger (et de mes applications), je conviens que la direction de la cartographie du type déclaratif est dangereuse (par exemple, par des annotations ou des attributs) .
De plus, je ne suis pas totalement satisfait de aucun des interfaces actuelles des conteneurs de COI, donc je ne sais pas que je veux celui que je choisis de dicter.
@Ryan: Bien que je suis d'accord avec Type-Safety sur XML, je pense que vous trouverez que vous avez une classe (peut-être même une méthode) qui effectue toute l'enregistrement d'un projet donné. En fonction du nombre de projets que vous avez, l'enregistrement d'abstraction peut fournir peu d'avantages.
Il est préférable de faire quelque chose que s'il y a un besoin réel de celui-ci et ne code jamais quelque chose que vous devinez parfois être nécessaire à l'avenir (c'est le soi-disant Yagni -principle). Si votre architecture est correcte, vous pouvez facilement changer le conteneur, s'il doit en fait devenir nécessaire ...
Si vous pensez avoir besoin de ce type de flexibilité, vous pouvez regarder le Projet de localisation de service commun à Codépex. Il fait exactement ce que vous recherchez: fournir une façade commune pour divers conteneurs de COI.
hth!
Parfois, vous devez faire une supposition éduquée sur les besoins de maintenance de votre application à l'avenir. Je préfère avoir un certain niveau de vérification future, bien que je suis confortable de manière globale par le principe de Yagni. Une bibliothèque unique, réutilisable et d'encapsulation (et tests associés) nécessite un tel effort minimal qu'il vaut la peine d'être envisagé.
Je suis avec Thomas (et Doug) - ça seul semble comme un effort minimal maintenant. Il ajouterait plus de code à tester, plus de code pouvant casser, et plus de code à maintenir. Et pour quoi? Pour vous sauver un peu de temps sur quelque chose qui pourrait ne jamais arriver. Je dirais même probablement ne se produira jamais, car les types de choses que vous modifiez des conteneurs pour (par exemple, aller de l'injection axée sur les attributs aux mappages déclaratifs) sont les types de choses Cela ne serait pas couvert par une interface d'encapsulation.
Juste hors de curiosité: quel type d'application aurait "changer la mise en œuvre du conteneur de la COI" comme besoin de maintenance? Et BTW: si cela nécessite un «effort minimal» pour encapsuler le conteneur maintenant, il nécessitera alors moins d'efforts pour la modifier à l'avenir, si ce besoin est vraiment survenu ...
Plutôt que d'encapsuler le conteneur de la COI lui-même, je préfère isoler le locus d'interaction avec le conteneur de la COI. Par exemple, dans ASP.NET MVC, je limite généralement l'exposition au conteneur à l'usine de contrôleur et le fichier global.aspx.cs, où il est généralement configuré.
Dans mon esprit, avoir beaucoup de code qui sait sur le conteneur de la COI est un anticitatoire qui augmente la complexité. J'ai vu une belle quantité de code dans lequel les objets n'hésirent à demander au conteneur de la COI pour leurs dépendances, puis ils ont essentiellement réduit le conteneur de la COI à un localisateur de services de maintenance élevé.
Depuis que les conteneurs IOC peuvent résoudre les dépendances à un degré de profondeur arbitraire, il est assez facile de rendre l'usine de contrôleur le composant responsable de l'inversion des conteneurs de contrôle. Le constructeur de chaque contrôleur spécifie essentiellement les services / référentiels / passerelles dont il a besoin.
Pour l'une de mes applications, l'échange du conteneur de la COI serait essentiellement une question de réécriture du code qui configure le conteneur (spécifie les liaisons, etc.) et connecte l'usine de contrôleur. Pour les applications exposées en tant que services, la même idée de base devrait être raisonnablement gérable, mais en fonction des contraintes de votre heure d'exécution, vous devrez peut-être utiliser l'injection de réglage plutôt que sur l'injection de constructeur.
Ça a été fait. (Pour .NET, au moins.) Bibliothèque de localisateur de services communs en tout cas, je suis d'accord avec M. Kneesek . Vous n'avez généralement besoin que de dépendances sur votre conteneur dans votre classe de haut niveau.
Cela semble un peu comme la surkill pour ce que j'essaie d'atteindre. Je veux juste minimiser l'impact du changement Devrais-je choisir de modifier des conteneurs (dans mon projet actuel ou des projets futurs). Je ne veux pas introduire une autre bibliothèque de tiers pour accomplir cela.
Adressé sensiblement dans Davybrion.com/blog/2009/ 11 / ...