Discussion :

[RaelRiaK]

Bonjour,

Je développe une application de Gestion de production pour l'entreprise pour laquelle je travaille. Il se trouve que le logiciel doit fonctionner dans plusieurs secteur. Ces secteurs ont des besoins commun dans 95% des cas, donc je compte ne développer qu'une seule application et pour les quelque différence je compte créer des extensions installable (sortes d'Add-In).

Techniquement je sais parfaitement comment le réaliser, mais vu le nombre de technique que je pourrais employer, j'aimerais savoir comment vous vous feriez, histoire de ne pas opter pour quelque chose ui me limiterais par la suite.

Ces extensions doivent êtres capables de :
- Modifier le menustrip de la fenêtre principale (MDI)
- Modifier certains aspect graphique de certains formulaire de l'application
- Rajouter des formulaire
- S'activer ou se désactiver depuis le menu des préférences

Techniquement je pense utiliser le système de réflexion dotNet notamment avec l'objet Assembly et les méthodes GetTypes etc ...

Avez vous des idées s'il vous plait
Merci
Renaud

[cinemania]

En fait la meilleur solution est de développer un coeur (Core) de ton application, qui va gérer les intéractions entre les différents "Modules" ou "Plug-ins", comme les lister, les charger dynamiquement ou pas...

Moi je suis dans le cas d'une appli ultramodulaire... j'ai donc un noyau (enfin micro faut le dire vite...) qui implante la gestion des interactions entre les modules.
En fait tout est ultra modulaire, puisque chaque couche peut etre elle meme dévisée en modules différents. Ensuite j'y ajoute également les classes Tools que tout le mnde utilise, comme des collections spécifiques, plus souples que celles du framework, des structures de données pas implantées dans le framework, ou mal... des interfaces communes pour chaque couche.
Ensuite le noyau ce charge de règler de par sa configuration les modules à charger et pour qui en fonction des dépendances.
J'ai donc pour la couche communication un générateur HTML, dont un module métier dépend... il indique une dépendance à ces interfaces et le noyau s'occupe de tout.

Tu comprendra que dans des cas pareils, System.Reflexion est le namespace le plus utile, d'ailleurs il est pour ainsi dire utilisé dans pratiquement toutes les classes du noyau, sauf celles représentant des structures de données spécifiques.

Cependant il faut faire attention, la Reflexion est un outil puissant, permettant de faire des choses hallucinante mais cela à un cout non négligeable sur les performances.

[AP]

Un très bon exemple (fruit de beaucoup de réflexion (sans jeu de mot ) est le système de sharpdevelop où même les plugins peuvent étendre leur fonctionnalités à l'aide de plugins.
Par chance le noyeau gérant cela (sharpdevelop core), est gratuit et réutilisable.
plus de renseignements:
http://laputa.sharpdevelop.net/AddIn...oTutorial.aspx et
http://www.codeproject.com/csharp/ICSharpCodeCore.asp

[RaelRiaK]

Tout d'abord merci pour vos conseil!

Ensuite j'ai continué mes petites investigation, et pour l'heure j'ai fait un petit projet de demo avec son add-in.

En fait j'ai tout créé par interface. Le programme principale utilise une interface décrivant le format d'une Add-In. Dans cette interface je décris toutes les méthodes qui doivent être appelé depuis le programme principale vers l'add-in (exemple, une sub Init qui sera exécuter lors du chargement de l'add-in sur ouverture du programme, ou encore un sub à exécuter sur ouverture d'un formulaire particulier).

Quand on développe un add-in, il faut qu'on implémente de cette interface, ensuite, on code les seule fonctions utiles.

Enfin j'ai créé une autre interface décrivant cette fois le paramètre que l'on passe sur appel d'une sub de add-in. Cette interface décrit au moins un menu et un panel pour pouvoir agir graphiquement avec mes formulaires et leur menu. La gestion des évènements se fait à l'interieur des add-in. Cela fonctionne bien et ne nécéssite pas trop de code. De plus le codeur est guidé quand au développement d'un add-in.

Les objet d'initialisation sont stockée dans une collection dans un objet paramétre qui suit toute l'exécution du logiciel.

Bien sur le tout fonctionne au travers de System.Reflexion

Je ne sais pas si c'est le plus propre, qu'en pensez vous ?

[AP]

Ce n'est peut être pas le plus propre mais c'est assez léger à mettre en place. Si cela correspond à tes besoins, ne cherche pas plus loin!

[RaelRiaK]

Il me semble que cela répond correctement a mes besoin.
Merci pour votre aide

Renaud