Bonsoir la team, voici une question limite philosophique
Je cherche à pouvoir utiliser des classes POCO contenues dans des DLL qui sont injectées dans mon soft (des plugin donc) via Ninject.
J'ai créé un premier bind sur une interface IMenu qui autorise les DLL à insérer les icônes et les boutons dans la barre du menu du logiciel hôte.
Les événements clics fonctionnent et mes DLL gèrent sans problème la gestion de la base Sqlite commune.
Les formulaires de gestion DAO tournent (add, modif, remove, list,...) parfaitement.
Exemple de plugin :
Une DLL pour les contacts, une autre pour les civilités et disons une troisième pour les sociétés ou les villes. Chacune intègre une table dans la BDD commune et contient le POCO et le PocoManger d’accès à la base.
je suis clair ?
Voici ma question :
Comment puis-je faire pour que la DLL société par exemple puisse lire et intégrer un contact ?
En effet, à cause (ou grâce) à l'injection de dépendance personne ne connait personne dans le code, c'est qu'a l’exécution que les plugins sont lues. D'autant que cette architecture et faite pour pouvoir ajouter une nouvelle fonctionnalité (table ou autre) sans rien toucher, ni recompiler
Voici mes idées, pouvez-vous me donner votre vision des choses ? D'avance merci pour vos conseils et idées.
- copier toutes les classes poco+pocoManager dans une DLL commune à la solution pour que chaque plugin puisse les utiliser. (à re-distribuer à chaque ajout de plugin :/)
- créer une interface pour chaque POCO dans le prog hôte ? (nécessite de recompiler le prog à chaque ajout de plugin donc pas malin malin)
- copier les Poco utile dans les DLL qui en auront besoin (pareil si je modifie un POCO faut tout recopier et recompiler :/ )
- à vrai dire je sèche pour les autres idées, style injecter dans les plugins un plugin (idem niveau compilation global et surtout je risque des injections circulaires et puis ajouter une forte dépendance et loin d'être la solution à mon sens)
Partager