Q1 Si j'ai une bibliothèque réutilisable disponible, qui utilise des interfaces avec des classes qui utilisent le concept getInstance pour créer des classes concrètes à utiliser, alors dans ce cas est-il logique du côté client d'utiliser le conteneur IOC pour créer des instances de ces classes? Ou est-ce vraiment appliquer une double couche d'abstraction? Q2 Ou dans les cas où je construis moi-même la bibliothèque réutilisable et que je veux que le client utilise un conteneur IOC, alors dans ma bibliothèque réutilisable je me passerais de toute surcharge d'avoir des usines ou des méthodes "getInstance" à instancier les classes dans le client? (c'est-à-dire que le conteneur IOC le ferait non?)puis-je utiliser le CIO lors de l'utilisation d'une bibliothèque tierce
0
A
Répondre
1
Q1. Le getInstance vous parle de localisateur de service, pas d'injection de dépendance. Si c'est le cas, alors oui, je l'emballerais dans mon conteneur IoC de choix.
Donc, si je suppose que l'utilisateur va utiliser un conteneur IOC alors il n'y aura pas d'usines nécessaires? Donc, pour que la bibliothèque fonctionne, l'application client doit avoir un conteneur IOC qui utilise l'injection de constucteur correcte? Mais qu'en est-il de la façon spécifique dont le CIO se configure? La bibliothèque ne devrait-elle pas avoir une config spécifique au conteneur IOC qui relie les classes? Par exemple Ninject. Ou serait-il préférable d'installer un conteneur IOC séparé dans la bibliothèque pour qu'il soit auto-suffisant (pas exactement sûr comment cela fonctionnerait)? – Greg
Vous devrez fournir un "adaptateur" pour chaque conteneur que vous voulez prendre en charge. Par exemple. une installation de Windsor, un registre StructureMap, un module Ninject, etc. –