Problème d'architecture, définition des assemblys

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.

Citation:

---

Envoyé par WebPac

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 ?

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.

Citation:

---

Envoyé par 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.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.

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

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 ?

salut,

un projet utilise des "références" vers des assemblys externes ou internes (d'autres projets dans ta solution)

quand tu compiles, le compilateur vérifie que tous les objets issus de tes références, sont compatibles avec le code du projet que tu compiles.

donc tu n'a pas besoin de vérifier les versions des assemblys. VS le fait pour toi.

dans ton exemple les classes filles seraient en erreurs.

concernant le versioning tes projets utilise un fichier assembly.info, dans lequel il y'a le numéro de version.

bon courage

Salut, sur le poste du developpeur, tout va bien car on ne lance les produits qu'à partir de VS (en tout cas dans 90% des cas), je me pose plutôt la question pour les postes utilisateurs. Il peuvent déplacer ou remplacer à la main des dll ou exe sans passer par setup pensant qu'un nouvel exe patchera un bug sans penser à remplacer toutes les dll.

De façon plus générale, dans ma solution, j'ai plusieurs applications qui réutilisent des dll communes, il faudra qu'à terme, je fasse un setup qui permette la mise à jour des applications sans avoir à désinstaller au préalable les anciennes versions. Si l'utilisateur ne met pas à jour toutes les applications, il y aura forcément des problèmes de version entre certaines assemblies.

dans chacun de tes répertoires d'installation tu auras tes DLL de références, au besoin dans différentes version.

sinon tu peux enregistrées tes DLL dans le GAC ; là tu sors la grosse artillerie...

Vu que les applications font parties de la même solution et qu'elle utilisent les même dll je compte les mettre dans le même répertoire d'installation afin de ne pas avoir à dupliquer les dll.

Comment enregistrer les dll dans le GAC me permet de garantir les bonnes versions des dll ? Faudra-t-il que le setup se connecte au GAP pour vérifier les différentes dll ?

Je note comme [Résolu] car le sujet de départ a sa réponse et pour le reste, je suis en train de faire de la R&D sur la MSDN et pense qu'au final, je vais le gérer via le setup d'installion & vérifier les versions des assemblies au lancement des applications et demander des mises à jour si elle ne sont pas bonnes.

Merci pour tout, ++