Discussion :

[WebPac]

Bonjour tout le monde,

je souhaite faire plusieurs applications qui pourront exporter dans un tableur, soit dans Excel soit dans OpenOffice.org.
Il y aura au final, une suite pour Excel et une suite pour OpenOffice.org.
Les 2 suites ont bien entendu tout le code métier en commun, seul le code de pilote des tableurs change.
Ainsi, je désire créer une dll ExportExcell.dll et une dll ExportOOo.dll.
Chacune de ses 2 dll possèdera le code spécifique associé au tableur lui correspond et les projets et autres dll métier n'auront aucun code spécique à tel ou tel tableur.
Jusque là, rien de bizarre, juste une volonté de faire un code propre.

Ainsi, la solution est de faire une interface Tableur avec 2 classes filles TableurExcel et TableurOOo, chacune des 2 filles se trouvant dans une des 2 dll et création des filles en utilisant un design pattern Fabrique abstraite.

Mon soucis est que je ne sais pas où définir mon interface Tableur, en effet, si je souhaite la déclarer dans mon projet principal métier, il faudra que les dll puissent y avoir accès et ce n'est pas faisable car mon projet principal doit déjà pouvoir y accéder, de plus, je ne voudrais pas que les dll dépendent du code métier.

Si je déclare l'interface Tableur dans une assembly séparée, ça me fait créer une dll qui ne possèdera qu'une déclaration d'une interface, je trouve que c'est un gaspillage pour pas grand chose et une complication de l'architecture.

Quelle est la solution en général pour ce genre de problème d'architecture ?
Je ne vois pas mais me dis que je ne suis pas le seul à me poser ce problème.

Merci par avance pour vos suggestions.

[Bluedeep]

Si je déclare l'interface Tableur dans une assembly séparée, ça me fait créer une dll qui ne possèdera qu'une déclaration d'une interface, je trouve que c'est un gaspillage pour pas grand chose et une complication de l'architecture.

C'est pourtant la solution la plus commode.
On l'applique courament avec WCF, par exemple où le seul point commun entre le serveur et le client sont souvent les BO et les interfaces de communication.

Je ne comprends pas la notion de "gaspillage" ici ? ca gaspille quoi ? 10 Ko sur le disque ?

[WebPac]

Salut,

en fait, non, "gaspillage" n'est pas un bon terme, c'est que je me dis que si je commence à créer des assembly pour des interfaces uniques, je vais me retrouver avec un nombre assez conséquent d'assembly au final.

Mais de toute façon, je ne voyais pas d'autre solution, donc si c'est ainsi la bonne pratique, je valide et fais aussi ainsi.

[Bluedeep]

Salut,

en fait, non, "gaspillage" n'est pas un bon terme, c'est que je me dis que si je commence à créer des assembly pour des interfaces uniques, je vais me retrouver avec un nombre assez conséquent d'assembly au final.si.

Quelques dizaines d'assemblies dans une application c'est assez fréquent, tu sais.

Une petite application, c'est souvent une dizaine d'assemblies.

[titom59]

salut,

tu peux même aller plus loin.

- tu peux étudier le chargement dynamique de DLL qui te permettra de rompre le lien d'implémentation.

- faire une assembly permettant de switcher entre OpenOffice et Excel

après il faut savoir si c'est vraiment nécessaire.

parfois une bonne DLL avec une gestion de version correcte permet de faire des choses propres et efficaces.

enjoy

[WebPac]

Merci pour vos réponses, en fait, je suis nouveau en .NET avec un grosse expérience en Delphi, donc pas de dll mais un gros exécutable qui intègre tout.
Je me pose des questions justement sur les problèmes de versionning des assemblys, si une classe mère se trouve dans une assembly et des classes filles dans d'autres assemblies, si on modifie la déclaration de la classe mère (ajout de propriétés, méthodes, changement de signature de méthodes) et qu'on n'a pas les même versions des assemblies, que se passe-t-il ?

Peut-on vérifier à l'exécution que les versions sont bien les bonnes ?