Do generated from xsd schemas proxy classes really bring value?

All is OK when proxy classes are easily generated from xsd/wsdl (which in turn are often generated from the classes).

But when wsdl/xsd are not from MS world, given as the zip package with tens or even hundreds of files, then proxy generation as a rule fails. In this case will you try to understand what's wrong, may be try to correct wsdl, find types that you need and left only them, find missed includes etc, or give up and live without proxies?

I don't feel discomfort querying XmlDocument with xpath, and creating backbone documents from string/file templates, but each time I meet "bad" wsdl/xsd I spent some time to correct it... and regret about this later even when succeed, since setting up endless proxy's fields is the very same thing as setting up endless document's elements and attributes.

What value do proxy classes bring to developer except some primitive compiler checks? May be I开发者_JS百科 forgot something...

Generally I've had a pretty positive experience working from xsd. On the few occasions it has failed, I've found a pragmatic approach (if you have sample xml available) is to use the xsd.exe tool to generate something that even if not ideally typed, at least matches the xml. Of course, you might need to live with a few more string members that you like, or tweak them manually.

Tweaking the xsd (to account for any changes not in your copy, or to hack away xsd options not supported by your tooling) might be a sensible option, but it is hard to gauge how long you might need to spend on that route.

Re the value: well, when it works it is a pretty fair way of getting an object-model that can serve as a DTO layer. And usually it does work. But not quite always. It sounds like your scenario has large/complex/multiple xsd, so doing all that translation code by hand (either via xml querying, or writing your own DTO model from scratch) can be a lot of work.

Xsd can (and should) also be used as a tool to validate that the xml you are passing around continues to adhere to a published definition. When dealing with xml data-imports I have, on multiple occasions, made the first step a scan through an xsd validator (fortunately XmlReader will do that in .NET).