Objets volumineux et complexes en tant que résultat de service Web [fermé]

Question

Re-bonjour mesdames et messieurs !

OK, suite à mon autre question sur Résultats du service Web ASP.NET, classes proxy et conversion de type.Je suis arrivé à une étape de mon projet où je dois réfléchir.

Fondamentalement, nous avons un objet personnalisé volumineux et complexe qui doit être renvoyé par un service Web et consommé dans l'application client.

Maintenant, sur la base de la discussion précédente, nous savons que cela prendra alors la forme d'une ou plusieurs classes proxy comme type de retour.Pour surmonter ce problème, nous devons essentiellement copier les propriétés de l’une à l’autre.

Dans ce cas, c'est quelque chose que je voudrais vraiment, vraiment, vraiment! j'aime éviter !

Alors, ça m'a fait réfléchir, comment pourrions-nous faire cela autrement ?

Mes pensées actuelles sont d'activer la sérialisation complète de l'objet en XML, puis de renvoyer le XML sous forme de chaîne à partir du service Web.Nous désérialisons ensuite chez le client.Cela signifiera pas mal de décoration d'attributs, mais au moins le code aux deux points de terminaison sera léger, notamment en utilisant simplement le sérialiseur XML .NET.

Que pensez-vous de ceci?

Answer 1

La (dé)sérialisation .Net XML est assez bien implémentée.À première vue, je ne pense pas du tout que ce soit une mauvaise idée.

Si les deux applications importent la ou les mêmes définitions de classe C#, il s'agit alors d'un moyen relativement intéressant d'obtenir gratuitement le comportement du constructeur de copie.Si la structure de classe change, alors tout fonctionnera lorsque les deux parties obtiendront la nouvelle définition de classe, sans qu'il soit nécessaire d'apporter des modifications supplémentaires du côté de la consommation/construction du service Web.

Il y a une légère surcharge liée au marshalling et au démarshalling du XML, mais elle est probablement éclipsée par la surcharge de l'appel du service Web distant.La sérialisation XML .Net est bien comprise par la plupart des programmeurs et devrait produire une solution facile à maintenir.

Answer 2

J'aime JSON pour ce genre de chose.Je viens de terminer un portail de type POC drop-things pour mon entreprise en utilisant jQuery pour contacter les services Web avec le service de script activé.Les messages sont légers et l'analyse, etc., est à peu près gérée.Le jQuery ajax les trucs que j'ai lus étaient ici (j'adore ça !) : article jquery-ajax

Answer 3

J'ai eu hier d'excellentes réponses sur un sujet très similaire qui pourraient vous être utiles :

Communication entre javascript et le serveur

Answer 4

Rob, en regardant votre autre question ainsi que celle-ci, cela ressemble à la situation exacte que nous avons dans notre environnement.Cependant, ce que nous avons fait, c'est s'éloigner des services Web ASP.Net vers les services Web WCF et, ce faisant, résoudre (en grande partie) ce problème.

S'il y a une chance que votre service Web puisse être implémenté en tant que service Web WCF, cela pourrait également fonctionner pour vous.Je dois mentionner qu'en même temps, nous avons maintenu la compatibilité ascendante avec certaines applications clientes qui nécessitent le "style de service Web ASP.Net" d'implémentation en utilisant la liaison WCF basichttp pour le transport de service.Le résultat final est que nos applications client "plus récentes" sont capables d'utiliser nos objets métier réels (en faisant référence à un assembly contenant uniquement ces objets partagés) comme types de retour des appels de service Web, car elles effectuent de véritables appels WCF.

Nous faisons cela en n'utilisant pas les classes proxy générées automatiquement et en construisant notre propre canal client pour communiquer avec le service WCF.

Si vous pouvez éventuellement utiliser WCF, faites-moi savoir que je peux publier des informations supplémentaires.