Oggetti grandi e complessi come risultato di un servizio Web [chiuso]

Question

Ciao ancora signore e signori!

OK, faccio seguito alla mia altra domanda Risultati del servizio Web ASP.NET, classi proxy e conversione dei tipi.Sono arrivato a un punto del mio progetto in cui ho bisogno di concentrarmi su ciò che penso.

Fondamentalmente, abbiamo un oggetto personalizzato grande e complesso che deve essere restituito da un servizio Web e utilizzato nell'applicazione client.

Ora, in base alla discussione precedente, sappiamo che questo assumerà la forma delle classi proxy come tipo restituito.Per superare questo problema, dobbiamo sostanzialmente copiare le proprietà dall'uno all'altro.

In questo caso, è qualcosa che vorrei davvero, davvero, Veramente! piace evitare!

Quindi, mi ha fatto pensare, in quale altro modo potremmo farlo?

I miei pensieri attuali sono abilitare l'oggetto per la serializzazione completa in XML e quindi restituire l'XML come stringa dal servizio Web.Quindi deserializziamo sul client.Ciò comporterà un bel po' di decorazione degli attributi, ma almeno il codice su entrambi gli endpoint sarà leggero, ovvero utilizzando semplicemente il serializzatore XML .NET.

Quali sono i tuoi pensieri a riguardo?

Answer 1

La (de)serializzazione .Net XML è implementata piuttosto bene.A prima vista, non penso affatto che sia una cattiva idea.

Se le due applicazioni importano le stesse definizioni di classe C#, questo è un modo relativamente carino per ottenere gratuitamente il comportamento del costruttore di copia.Se la struttura della classe cambia, tutto funzionerà quando entrambe le parti riceveranno la nuova definizione di classe, senza la necessità di apportare ulteriori modifiche sul lato del consumo/costruzione del servizio Web.

C'è un leggero sovraccarico nel marshalling e demarshalling dell'XML, ma probabilmente è sminuito dal sovraccarico della chiamata al servizio Web remoto.La serializzazione XML .Net è ben compresa dalla maggior parte dei programmatori e dovrebbe produrre una soluzione di facile manutenzione.

Answer 2

sto amando JSON per questo genere di cose.Ho appena finito di utilizzare un portale di tipo drop-thing POC per la mia azienda jQuery per contattare i servizi web con il servizio script abilitato.I messaggi sono leggeri e l'analisi, ecc., è praticamente gestita.IL jQuery ajax le cose che ho letto erano qui (lo adoro!): articolo jquery ajax

Answer 3

Ieri ho ricevuto alcune ottime risposte su un argomento molto simile che potrebbero esserti utili:

Comunicazione tra Javascript e il server

Answer 4

Rob, guardando l'altra tua domanda oltre a questa, sembra che sia l'esatta situazione che abbiamo nel nostro ambiente.Ciò che abbiamo fatto, tuttavia, è stato passare dai servizi Web ASP.Net ai servizi Web WCF e nel processo abbiamo risolto (per la maggior parte) questo problema.

Se esiste la possibilità che il tuo servizio Web possa essere implementato come servizio Web WCF, questo potrebbe funzionare anche per te.Dovrei menzionare che, allo stesso tempo, abbiamo mantenuto la compatibilità con alcune applicazioni client che necessitano dello "stile servizio Web ASP.Net" di implementazione utilizzando l'associazione WCF basichttp per il trasporto del servizio.Il risultato finale è che le nostre applicazioni client "più recenti" sono in grado di utilizzare i nostri oggetti business reali (facendo riferimento a un assembly contenente solo questi oggetti condivisi) come tipi restituiti dalle chiamate al servizio Web perché effettuano chiamate WCF effettive.

Lo facciamo non utilizzando le classi proxy generate automaticamente e costruendo il nostro canale client per comunicare con il servizio WCF.

Se riesci a utilizzare WCF, fammi sapere che posso pubblicare alcune informazioni aggiuntive.