Discussion :

[adn56]

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.

1. 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 :/)
2. 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)
3. copier les Poco utile dans les DLL qui en auront besoin (pareil si je modifie un POCO faut tout recopier et recompiler :/ )
4. à 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)

[adn56]

un peu de code pour que voyez ou j'en suis :p

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
            // Dans le MAIN : lecture du répertoire des dll plugins
            Kernel.Load("plugins/*.dll");
 
            // renseigne la liste des plugins trouvés IMenu
            listeMenus = Kernel.GetAll<IMenu>().ToList();
            // archive la list des plugins trié par ordre de chargement selon le prédicat Ipluging.ordre (linq)
            listeMenus = listeMenus.OrderBy(e => e.ordre).ToList();
// ok
// test concluant mais je ne vois pas trop quoi en faire puisque je ne peux pas m'en servir dans le code (c'est la que ma compréhension de l'IOC touche à l’incompréhension ^^ )
            // liste des tables.
            listeTables = Kernel.GetAll<ITable>().ToList(); //ITable ne contient que ID et NOM donc pas super utile
            // liste des Managers.
            listeManagers = Kernel.GetAll<ITableManager<ITable>>().ToList(); // toujours vide ne trouve pas les manager BDD
 
            Application.Run(new Form1());

[adn56]

En attendant vos idées, je me lance dans la solution 1 qui me semble efficace et maintenable.
@++

[mermich]

Salut,

Hmm si j'ai bien compris tu cherches a faire interagir des plugins entre eux c'est bien ca ?

Dans, ce cas je partirai sur la solution suivante ( qui n'est pas forcement la meilleure) :

• Chaque plugin implentente une interface (logique)
• Chaque methode de plugin peut lancer des evenements (possible)
• Ton programme maitre recupere ces evenements
• Et appelles d'autres plugins en consequence => tu va devoir ici faire un mapping entre evenement plugin1 et action plugin2 (statique dans le code, ou dynamique via un backoffice par exemple).

Avec cette solution, ca devrai le faire, tu restes full plugin et propre (pas de copie de dll), pas de recompile etc (par contre c'est pas intuitif et bonjour le debug).

[adn56]

En effet tu as tout bon, c'est pourquoi j'opte pour la solution de la DLL commune à tous les plugins.
C'est facile à maintenir, elle contient les classes poco, manager et la gestion de la BDD.
une simple référence, un résoudre et hop chaque plugins connait et peut utiliser les poco des autres plugins
Dans l'attente de poursuivre cette conversation je continu sur cette voie qui semble convenir.
Bien cordialement ADN