Web Service + Proxy = 2 différents objets

Version imprimable

30/12/2007, 21h42
superdaok84

Web Service + Proxy = 2 différents objets

Bonjour à vous tous,

Je débuter avec les Services Webs. J'ai fais plusieurs tests avec des données simples et des objets simples. J'entends pas simple par de tableau, pas de liste, juste des données brutes.

Je réussi a bien avoir mes données lorsque je le test dans le navigateur web, cependant, dans mon code, il arrive que l'objet de retour du service web n'est pas du même namespace que l'original. En regardant dans le code généré du Proxy, je me rends compte qu'il a fait une copie de mes classes et qu'il retourne cet objet au lieu de l'orginal. Quoi faire?

Merci
30/12/2007, 21h56
Skyounet

Il est tout à fait normal que ce soit une copie de la classe.

Dans ton webservice tu mets juste à disposition la structure de ta classe, lorsque tu crées ta classe proxy, wsdl.exe te crée une classe avec le même nom, et les mêmes membres/propriétés.

C'est tout.

Citation:

Envoyé par Skyrunner

Il est tout à fait normal que ce soit une copie de la classe.

Dans ton webservice tu mets juste à disposition la structure de ta classe, lorsque tu crées ta classe proxy, wsdl.exe te crée une classe avec le même nom, et les mêmes membres/propriétés.

C'est tout.
Code:

1 2 3 4 Stub.StubObjectWithListObjectNotSerialized stub; WebServiceReference.ServiceFacade wsFacade = new NunitTest.WebServiceReference.ServiceFacade(); stub = wsFacade.getComplexObject();
Pourquoi est ce que alors tout crash à la ligne stub = wsFacade.getComplexObject();

Je ne vois pas le but de faire une copie lorsque lorsque je consomme le service je ne peux pas récupérer l'objet car il est rendu un autre objet... je veux le même objet.

30/12/2007, 22h16
Skyounet

Je ne comprends pas ce que tu essais de faire.

Comment veux tu que la WebMethod getComplexObject() connaisse la classe StubObjectWithListObjectNotSerialized ?

Le code de la classe est aussi présent sur le serveur (là où se trouve le WS quoi).

Le classe est sérializable ?

D'ailleurs tu dis que ça crash, quelle est l'erreur ?
30/12/2007, 22h20
superdaok84

Citation:

Envoyé par Skyrunner

Je ne comprends pas ce que tu essais de faire.

Comment veux tu que la WebMethod getComplexObject() connaisse la classe StubObjectWithListObjectNotSerialized ?

Le code de la classe est aussi présent sur le serveur (là où se trouve le WS quoi).

Le classe est sérializable ?

D'ailleurs tu dis que ça crash, quelle est l'erreur ?

J'ai mon DLL (namespace) côté serveur et côté client.

Ce que je veux faire c'est que mon client appelle mon serveur (web service). Le webservice va à la DB fait les calculs et le tralala du côté serveur. Lorsque mon objet est prêt il renvoie mon objet tout rempli et je l'utilise côté client.

Client--call-->webservice--return-->Client

Je ne comprends pas pourquoi le Proxy me crée un objet car lorsque je retourne vers le client bien rien n'est compatible. L'erreur est que ce n'est pas le bon objet tout simplement. J'essaye de le Caster et ca ne marche pas.
30/12/2007, 22h30
Skyounet

Je n'ai jamais été confronté à cette situation.

Mais comment veux tu que le serveur sache que le client connaisse le code de la classe.
Il ne sait pas, donc il fout la structure dans ta classe proxy.

Récupère un objet du type qui est dans la classe proxy et après copie tous les champs 1 à 1.
30/12/2007, 22h43
superdaok84

Citation:

Envoyé par Skyrunner

Je n'ai jamais été confronté à cette situation.

Mais comment veux tu que le serveur sache que le client connaisse le code de la classe.
Il ne sait pas, donc il fout la structure dans ta classe proxy.

Récupère un objet du type qui est dans la classe proxy et après copie tous les champs 1 à 1.

Le client et le serveur ont chacun une copie du DLL avec les classes dedans. Je ne vois pas pourquoi ceci est impossible. À tous les fois vous transféré les attributs 1 à 1... ou vous utilisez directement la classe du Proxy dans vos application? Je ne trouve pas ceci très efficace.
30/12/2007, 22h48
Skyounet

Citation:

Envoyé par superdaok84

Le client et le serveur ont chacun une copie du DLL avec les classes dedans. Je ne vois pas pourquoi ceci est impossible. À tous les fois vous transféré les attributs 1 à 1... ou vous utilisez directement la classe du Proxy dans vos application? Je ne trouve pas ceci très efficace.

Oui mais imagine que moi je veuille créer une appli consommant ton webservice et que je n'ai pas cette DLL.

Comment je peux faire ?

Si tu veux travailler en local avec ton objet tu dois convertir ta classe de ton proxy en ta classe de ta DLL (copier les champs 1 à 1).

Sinon tu peux faire tout ton traitement sur ton serveur, mais là c'est plus lourd.

Sur ton serveur, est-ce que tu utilises des méthodes de ta classe .StubObjectWithListObjectNotSerialized ? Ou est-ce que tu remplis juste les champs ?
30/12/2007, 22h56
superdaok84

Citation:

Envoyé par Skyrunner

Oui mais imagine que moi je veuille créer une appli consommant ton webservice et que je n'ai pas cette DLL.

Comment je peux faire ?

Si tu veux travailler en local avec ton objet tu dois convertir ta classe de ton proxy en ta classe de ta DLL (copier les champs 1 à 1).

Sinon tu peux faire tout ton traitement sur ton serveur, mais là c'est plus lourd.

Sur ton serveur, est-ce que tu utilises des méthodes de ta classe .StubObjectWithListObjectNotSerialized ? Ou est-ce que tu remplis juste les champs ?

Ok, je commence à comprendre. Je voulais utilisez le webservice comme transporteur d'objet entre 2 machines. Il me semble que le webservice est plus un transporteur de donnée que d'objet! Oui j'utilise des méthodes côté serveur et côté client.
30/12/2007, 23h08
Skyounet

Ok sinon côté serveur t'aurais pu juste faire un conteneur de données. Sans méthodes sans rien.

Enfin bref, oui WS c'est pour transporter des données pas des objets. Pour ça tu as le Remoting.

Regarde c'est peut-être ça qu'il te faut.

Tu envoies ton objet au serveur il effectue des traitements dessus et après il te le redonne.
30/12/2007, 23h13
superdaok84

Citation:

Envoyé par Skyrunner

Ok sinon côté serveur t'aurais pu juste faire un conteneur de données. Sans méthodes sans rien.

Enfin bref, oui WS c'est pour transporter des données pas des objets. Pour ça tu as le Remoting.

Regarde c'est peut-être ça qu'il te faut.

Tu envoies ton objet au serveur il effectue des traitements dessus et après il te le redonne.

Je voulais utiliser les WebService au lieu de Remoting pour utiliser le Caching des WebService afin de diminuer la charge sur les BD... je vais trouver autre chose alors!
20/02/2008, 17h51
goomazio

Est-ce que vous auriez des articles, tutoriaux, etc parlant de cela ? Cette obligation de redéfinir tout notre web service (le proxy) dans notre projet qui utilise ce webservice, puis de nous dire que les objets qu'utilise le webservice ne sont pas les mêmes que les nôtres...

Le webservice n'est donc pas fait pour transporter des objets comme il l'est dit, mais un string ce n'est rien d'autre qu'un objet quand même.

Le problème parait encore plus abérant lorsque l'on constate que si on modifie le proxy (modifier le fichier reference.cs du projet utilisant le webservice) en y enlevant la définition de nos classes générée automatiquement par Microsoft.VDesigner (lors de l'ajout de la webreference, dans mon cas avec visual studio 2005), ça fonctionne super.

Je suis tombé sur un article indiquant comment utiliser les Schema Importer Extension (http://www.microsoft.com/belux/msdn/...s/wsproxy.mspx) permettant de spécifier à ce super visual studio qu'il ne doit pas redéfinir nos classes, qu'elles se trouvent dans notre namespace...

Je sais bien qu'il y a une raison à ne pas permettre ce que l'on veut faire (utiliser la même classe dans le webservice et dans notre projet utilisant ce même webservice), mais je ne la comprend pas :cry: ... Si vous avez donc d'autres explications, je les attends avec impatiente :D