WebService & DLL

Bonjour,

Après des heures de recherches infructueuses sur le net je me tournve vers vous comme ultime solution.. A titre informatif, j'utilise Delphi 7.

Je souhaite faire une appli liée a un WebService mais ne pas avoir à faire évoluer le .exe si le WebService évolue.

Je me suis donc orienté vers une DLL car je préfère faire évoluer une DLL qu'un Exe pour des raisons de maintenance. A Noter la DLL devra être chargée dynamiquement.

J'ai commencé par utiliser Delphi pour générer une unité via le lien WSDL du WebService (Importateur WSDL). A partir de là j'ai commencé ma DLL.

Je me pose cependant quelques question sur la faisabilité de la chose.

En parcourant les tutos j'ai eu l'impression que pour utiliser une DLL il fallait avoir une sorte de "moule" dans mon exe.

Par exemple :
1) Ma DLL possède une fonction "function Somme(a , b : Integer) : Integer;"
2) Pour l'appeler dynamiquement je vais devoir déclarer un type "TMyFunc = function(a, d : Integer) : Integer; stdcall;" (ce que j'appelle le "moule") pour ensuite passer un pointeur provenant de la DLL à un objet de type TMyFunc. Non?

J'espère être clair.

De la même manière pour les objets, j'ai cru comprendre que pour utiliser ces derniers il me faut :
1) Un objet similaire à celui de ma DLL dans mon Exe
2) Créer une fonction qui renvoie un pointer de l'objet de ma DLL pour alimenter l'objet de l'exe.

Du coup, j'ai plusieurs zones d'ombre:

-Si le fonctionnement est cloisonné comme présenté ci-dessus, quel intérêt aux DLL ?
Car si demain la fonction Somme de la DLL prend des Double au lieu des Integer en arguments et en retour, je suppose que je dois recompiler un exe pour mettre à jour le TMyFunc ?

-Ce que je voudrai ce serait que si la fonction ou l'objet évolue dans la DLL on n'ai pas besoin d'évoluer l'exe. Est-ce seulement possible ?

-Dernière question, j'ai vu quelques tutoriels parler de méthodes d'objets mais aucun de propriétés qu'en est-il sur ce point là, faut-il déclarer des méthodes getter/setter ? ou le READ/WRITE de la propriété suffit ?

Merci à vous !

Tout dépend ton niveau de mapping
Si ta DLL revient à mapper tous les types, tous les fonctions de ton WebService, tu as refait un Wrapper sans grand intérêt, pas de valeur ajouté au Wrapper généré par le WSDL

La DLL, faut la voir plutôt comme un plugin dans ce cas, tu as juste une poigné de fonction genre Initialize, Start, Stop, Finalize
L'exe lui il appelle une fonction qui fait plein de truc, il n'a pas besoin de connaitre l'intérieur, un minimum d'entrée et de sortie.
Là, tu rends ta DLL utile au cloisement.
Voit ta DLL comme une boite noire, l'exe n'a pas à savoir ce qu'il y a dedans.

Commence déjà par faire une classe qui encapsule le Wrapper TLB généré le WSDL
Gérer l'allocation et la libération, déjà ces petites choses ça aide
Puis essaye de voir ce que l'Exe a vraiment besoin, a-t-il besoin de tout ou plutôt d'un résultat final issu de plusieurs appels aux WS.
Déjà la structure POO sera un bon début


une DLL qu'elle soit type WinAPI (juste un ensemble de fonction) ou qu'elle soit COM (trois fonctions dont la factory des interfaces, les interfaces sont une autre forme d'ensemble de fonction, les propriétés c'est 100% par accesseurs)

je te conseille de voir ce "moule" vers les interfaces.
J'ai beaucoup utilisé les interfaces dans les DLL mais sans le modèle COM (ActiveX, Automation)
Tu as ainsi quelques fonctions pour obtenir ces interfaces
Ces interfaces pouvant contenir plusieurs versions, pour un WS c'est un peu moins vrai mais pour un format de fichier, tu fais une interface à chaque nouvelle version, qui gère les spécificités de telle ou telle version (un grand classique c'est Word et Excel)


La DLL, c'est plus pour fournir des fonctionnalités d'extension, par exemple, lorsque j'ai beaucoup pratiqué, j'avais trois cas :
- Soit c'est un COM\API utilisé par un tiers, tu ouvres une porte dans ton logiciel
- Soit c'est un déploiement partiel de module indépendant, certains interchangeables, selon le client, tu n'installes pas tout, les "bonus" c'est payant.
- Soit cloisonner et organiser un logiciel en un EXE qui n'est qu'un lanceur d'un tas de DLL, en gros chaque bouton, chaque menu dans la MainForm pointe vers une DLL\Fonction, un utilisateur qui va utiliser que 10% de l'application ne chargera que les DLL utiles, plein de fonctionnalités non utilisées ne consommeront pas de mémoire inutilement, mais bon ça c'était quand 256Mio était un luxe, maintenant avec 16Go sur un poste de bureau, qui s'occupe des performances ?

Maintenant tu as de la lecture avec autant de mot clé à chercher dans Google

Hey !
Sacrée réponse !
Merci d'avoir pris le temps de lire puis d'écrire quelque chose d'aussi argumenté.
J'ai noté ces pistes et effectivement j'ai des recherches a faire ;)