Groot, Komplekse Voorwerpe as'n Web Diens Hiervan [gesluit]

Question

Hallo weer dames en here!

OK, na aanleiding van my ander vraag op ASP.NET Web Diens Resultate, Proxy Klasse en Tipe Omsetting.Ek het gekom om te deel in my projek waar ek nodig het om te kry my denke cap op.

Basies, ons het'n groot, komplekse persoonlike voorwerp wat nodig het om te word teruggekeer van'n Web-Diens en verbruik in die kliënt aansoek.

Nou, gebaseer op die vorige gesprek, ons weet dit gaan dan neem die vorm van die volmag klas(es) as die terugkeer tipe.Om dit te oorkom, ons moet basies kopieer die eienskappe van die een na die ander.

In hierdie geval, dit is iets wat ek sou regtig, regtig, regtig! soos te vermy!

So, dit het my laat dink, hoe anders kan ons doen?

My huidige gedagtes is in staat te stel om die voorwerp vir die volledige serialisasie te XML en dan terug die XML as'n string van die Web Diens.Ons het toe de-serialize by die kliënt.Dit sal beteken dat'n billike bietjie van die kenmerk versier, maar ten minste die kode op beide eindpunte sal lig wees, naamlik deur net die gebruik van die .NETTO XML Serializer.

Wat is jou gedagtes oor hierdie?

Answer 1

Die .Netto XML (de)serialisation is mooi mooi geïmplementeer word.Op die eerste het gedink, ek dink nie dit is'n slegte idee nie.

Indien die twee aansoeke invoer dieselfde C# klas(es) definisie(s), dan is dit'n relatief lekker manier om kopie-constructor gedrag vir gratis.As die klas struktuur verander nie, dan sal alles werk wanneer beide kante kry die nuwe klas definisie, sonder om enige bykomende veranderinge op die web-diens verbruik/konstruksie kant.

Daar is'n effense oorhoofse in toesig en demarshalling die XML, maar dit is waarskynlik dwarved deur die oorhoofse van die remote web diens oproep..Netto XML serialisation is goed verstaan word deur die meeste programmeerders en moet produseer'n maklik om te handhaaf oplossing.

Answer 2

Ek is lief JSON vir hierdie soort van ding. Ek het net 'n POC vervolg dinge tipe portaal vir my maatskappy met behulp van jQuery kontak web dienste met script diens geaktiveer is. Die boodskappe is liggewig en ontleding ens is pretty much hanteer. Die jQuery ajax dinge wat ek lees is hier (liefdevolle dit!): jQuery Ajax artikel

Answer 3

Ek het 'n paar groot antwoorde op 'n baie soortgelyke onderwerp gister wat nuttig kan wees vir jou:

Kommunikasie tussen JavaScript en die bediener

Answer 4

Rob, in te kyk na jou ander vraag sowel as hierdie een, dit klink soos die presiese situasie wat ons in ons omgewing. Wat ons gedoen het, is egter weg te beweeg van ASP.Net web dienste te WCF web dienste en in die proses opgelos (vir die grootste deel) hierdie probleem.

As daar enige kans jou web diens kan as 'n WCF web diens geïmplementeer word, dit kan werk vir jou so goed. Ek moet noem dat op dieselfde tyd, het ons backwards compatibility met 'n paar kliënt aansoeke wat die "ASP.Net web diens styl" van implementering moet deur die gebruik van die BWF basichttp bindend vir die diens vervoer gehandhaaf. Die eindresultaat is dat ons "nuwe" kliënt aansoeke in staat is om ons werklike besigheid voorwerpe gebruik (deur verwysing 'n vergadering met net hierdie gedeel voorwerpe) as die tipes terugkeer uit die web diens oproepe omdat hulle werklike WCF noem.

Ons doen dit deur nie gebruik te maak van die outomaties gegenereerde proxy klasse en die bou van ons eie kliënt kanaal om te kommunikeer met die BWF diens.

As jy dalk WCF kan gebruik, laat my weet ek kan 'n paar ekstra inligting kan lewer.