Rester ouvert avec les conteneurs DI/IoC

Question

Je suis impliqué dans plusieurs projets Open Source qui, ensemble, fournissent un cadre de développement d'applications. La question que je me pose est de savoir quel (s) mécanisme (s) devrais-je prévoir pour les intégrer les uns aux autres? Sur le plan conceptuel, la réponse est claire - DI/IoC. Le "seul" problème est de décider lequel. Dans plusieurs installations nous avons utilisé StructureMap, mais ensuite un utilisateur est venu qui voulait seulement un des composants et voulait NInject. Donc, pour qualifier la question, comment dois-je faire pour construire mes composants afin qu'ils puissent être intégrés les uns avec les autres (et les tiers) en utilisant une variété de conteneurs DI/IoC. Le meilleur que je pouvais trouver était de séparer tout le code d'intégration en projets séparés et ensuite avoir un projet par conteneur IoC supporté, mais cela ressemble étrangement à IoC au carré.

Des idées brillantes? ou je pense juste trop dur?

P.S. pour les curieux: NDjango; Bistro; Workflow Server

Answer 1

Tant que vous développez des composants réutilisables, vous pouvez les implémenter dans un DI-friendly way without ever referencing any particular DI Container.

C'est seulement quand vous avez besoin de composer une application en cours d'exécution que vous avez besoin du conteneur DI, mais si je comprends bien, vous développez un framework, et il vaut mieux le garder neutre.

Answer 2

Voir this very related question (presque un doublon).

Pour vous inspirer de l'intégration de plusieurs projets tout en les gardant indépendants, voir le Castle Project.