même classe utilisée dans deux bibliothèques distinctes non compatibles?

Question

Entré par un cas curieux aujourd'hui, cela m'a fait penser à la façon dont le modèle d'objet dans Delphi fonctionne vraiment.

Le cas:

Nous avons importé un service SOAP qui exposent quelques méthodes, prendre des objets en tant que paramètres. Delphi génère des classes/interfaces que nous utilisons pour communiquer avec le service soap, et les objets utilisés comme paramètres héritent tous de TRemotable.

Pour différentes raisons, nous avons mis toute la communication avec le service de savon dans une DLL.

Nous avons ensuite tenté d'instancier les objets à envoyer dans l'exécutable principal et de les transmettre à la bibliothèque pour la sérialisation et l'envoi. Maintenant, cela n'a pas fonctionné, mais a donné une exception que je ne m'attendais pas.

Il a dit que l'objet que nous essayons d'envoyer au service de soap doit hériter de TRemotable, mais c'est le cas. En inspectant l'objet, nous pouvons voir que la classe est la classe importée du wsdl, et que la classe parente est en effet TRemotable. Construire avec des packages permet de résoudre ce problème.

La question:

Est-ce de sorte qu'une classe définie dans un fichier source, partagé entre deux bibliothèques, finit aussi différentes classes à l'exécution? Si oui, pourquoi? Pour autant que je sache, il devrait être acceptable de passer des objets entre les bibliothèques. Comment, alors, est-ce que le typage fort est assuré, et dans quelle mesure les instances d'objet seront-elles compatibles les unes avec les autres?

Answer 1

Oui, la même classe dans différentes DLL est différente. Les classes de chaque DLL seront chargées au moment de l'exécution et pointeront vers une autre mémoire, donc A.ClassType = B.ClassType échouera, même pour les mêmes fichiers source. Vous pouvez toujours passer les objets autour et ils fonctionneront correctement, sauf dans des cas comme celui-ci où il utilise "is" ou "as" pour comparer les classes elles-mêmes. Le typage fort est seulement assuré que le compilateur suppose que les classes correspondent lorsque vous compilez la DLL et l'application principale. Il n'y a aucune protection contre le chargement d'une DLL avec une version d'un objet et une application plus récente essayant d'utiliser une déclaration d'objet modifiée. Si vous voulez que vous ayez besoin d'utiliser des paquets.

Answer 2

Vous pouvez essayer de transmettre le paramètre en tant que TObject, et à chaque extrémité, vous pouvez le convertir en TRemotable. Je n'ai pas essayé ce cas particulier, mais je sais que j'ai passé TObject dans une DLL comme ça. J'ai aussi une DLL similaire pour SOAP, et dans mon cas cela ne fonctionnerait pas car ma DLL SOAP est compilée avec les bibliothèques SOAP D2007 et pour des raisons compliquées/héritées, le reste de l'application est D2005.