[C#]Gebruikte datasets NIET laten genereren bij WebReference

[OZ-Gump]

Situatie
We hebben een WebService die datasets teruggeeft aan de ene kant, en een (random) aantal aanroepende applicaties aan de andere kant. Omdat we de datasets die in de webservice gebruikt worden typed willen kunnen gebruiken en door moeten kunnen geven binnen verschillende lagen van onze applicaties, hebben we de datasets in een common DLL gezet welke gereferenced wordt zodra de webservice in een applicatie gebruikt gaat worden.

Een aantal basisopmerkingen:
- De webservice wordt alleen intern (binnen het bedrijf) gebruikt
- De keuze voor een webservice voor deze applicatie ligt vast

Probleem
Zodra een webreference gelegd wordt naar de webservice welke de datasets teruggeeft, worden de datasets aangemaakt aan de aanroepende kant. Binnen reference.cs wordt veel code gegenereerd voor de datasets en ook de XSD's zijn allemaal terug te vinden bij de web references. De datasets kunnen echter niet gecast worden naar hun originele vorm: de vorm die opgeslagen zit in de common DLL welke (dus) wel gereferenced is!

Oplossing
We hebben reference.cs aangepast zodat de gegenereerde datasets niet meer beschikbaar zijn, en een referentie naar de common DLL met de 'juiste' datasets toegevoegd, waardoor binnen de aanroepende applicatie de datasets gewoon gebruikt kunnen worden. Ook de gegenereerde XSD's zijn verwijderd. De situatie werkt!

Vraag
En dan heb je toch een vraag ??? Ja. Omdat de applicatie die we aan het maken zijn (de webservice) zeer waarschijnlijk generiek gaat worden voor het gehele bedrijf, zullen in de toekomst meer applicaties deze webservice gaan gebruiken. Het is nu geen enkel probleem om dit werkend te krijgen, maar in de toekomst moeten bij gebruik van de webservice dezelfde acties uitgevoerd worden die wij nu hebben uitgevoerd. Het zou een stuk netter zijn om de datasets niet automatisch te laten genereren... Heeft iemand hier ervaring mee? Wellicht dat een van de vele handige tooltjes bij Visual Studio ons hierbij uit de brand kan helpen?

Disclaimer
Ja, ik heb best wel een en ander opgezocht op google en hier op GoT. En zelfs MSDN is voorbij gekomen op mijn scherm. Misschien heb ik op de verkeerde termen gezocht, maar ik kwam dit zo 1-2-3 niet tegen...

[EfBe]

Je kunt dit niet voorkomen, iedere keer als jij de webreference refreshed wordt references.cs opnieuw aangemaakt.

Met typed datasets is dit niet een probleem overigens, omdat het schema wat IXmlSerializable.GetSchema terugeeft bij een typed dataset een schema is dat genoeg is om precies dezelfde typed dataset op de client aan te maken, en omdat je toch geen BL in een typed dataset kwijt kunt is dat op zich niet zo'n ramp.

Je kunt ook contract first met je webservice bezig gaan, gebruik dan deze tool:
http://www.thinktecture.c...ontractFirst/default.html

Die tool laat je ook de stubs genereren zoals vs.net dat doet, maar op een contract first basis, zodat je veel meer solide met je code omgaat.

Overigens zou ik meteen voor remoting kiezen als je service alleen intern gebruikt zou worden. Degene die voor 'webservices' heeft gekozen mag dan wellicht roepen dat die beslissing 'vast staat', maar ik vrees dat die persoon niet degene is die problemen zoals de jouwe oplost maar dat wel zou moeten doen (en dan dus door zou krijgen wat de gevolgen zijn van zn/haar beslissing)

[LoekD]

Geef ipv de datasets een XmlNode terug, waarin de geserialiseerde dataset staat. (datset.writexml)
Deserialiseer de dataset aan de clientkant weer. (dataset.readxml)

Nadeel: geen beschrijvende wsdl (maar het is toch voor intern gebruik)
Voordeel: zelfde types in client en server applicatie.

[OZ-Gump]

Op deze kom ik nog even terug...

Je kunt dit niet voorkomen, iedere keer als jij de webreference refreshed wordt references.cs opnieuw aangemaakt.

Dat wist ik. Ik dacht alleen dat er welicht een mogelijkheid in VS zou zitten om ervoor te zorgen dat de omschrijving van je dataset niet over de lijn gegooid zou worden. Maar omdat een webservice via het web aangeroepen moet worden, is het natuurlijk begrijpelijk dat dit altijd gebeurt, zodat de client ermee aan de slag kan.

Overigens zou ik meteen voor remoting kiezen als je service alleen intern gebruikt zou worden.

Waarom zie je meer voordelen voor het gebruik van remoting? Dat is namelijk een discussie die hier intern op dit moment erg actueel is, maar men lijkt als enige voordeel voor remoting te kunnen vinden dat je de logica beter gescheiden aan de serverkant kunt houden en dat de server in staat is state bij te houden terwijl je daarvoor bij een webservice kunstgrepen moet gaan uithalen.

@LoekD: ik zal er eens naar kijken, maar ik geloof dat, als het inderdaad persé een webservice moet worden, ik meer voel voor de contract first methode van eFBe.

@eFBe: thanks voor de link. Dat levert weer wat interessant leesmateriaal op. En het lijkt een mooie tool te zijn.

[EfBe]

OZ-Gump schreef op dinsdag 26 april 2005 @ 09:47:
[...]
Waarom zie je meer voordelen voor het gebruik van remoting? Dat is namelijk een discussie die hier intern op dit moment erg actueel is, maar men lijkt als enige voordeel voor remoting te kunnen vinden dat je de logica beter gescheiden aan de serverkant kunt houden en dat de server in staat is state bij te houden terwijl je daarvoor bij een webservice kunstgrepen moet gaan uithalen.

Nou, bij remoting heb je het gezeur niet met die proxy classes op de client die elke keer worden gegeneerd.

[Scare360]

Even daargelaten dat je hier absoluut geen DataSet voor wil gebruiken... gatverdamme, hoe gaat een toekomstige J2EE app jouw service consumeren?

Je kan ook gewoon prima je eigen proxy klasse bouwen en die referencen in toekomstige projecten. Een wsdl service en xsd data contract implementeren mag het probleem niet zijn.