Check out
Craig's view on the contract debate. Despite what you may think, I agree with most of what he says and do believe that developers using either approach can be successful if they have sufficient understanding. Building software is full of tradeoffs and compromises, pros and cons, and in the end you have to get the job done. Period. Whatever approach helps you accomplish that is the right one.
In fact, whenever I teach courses on Web services I start with a discussion on "
leaky abstractions" and point students to
Spolky's piece (it even made it into the official slides). I found over the years that you really had to motivate developers to learn about the mappings, otherwise they're happy to ignore it.
My opinion on this whole issue is based on these types of interactions with numerous WS developers and orgs in recent years. In my experience, those who don't hide behind an object model are typically more prepared to deal with leaky abstractions and, more importantly, stop them when they occur. Developers who invest in learning about XSD/WSDL (even if they don't code to it directly) are more likely to understand the myriad of mappings Craig describes than those who don't. That's the reality I see.
In fact, for most developers the whole motivation for going the code-first route is to avoid having to learn that "tedious" stuff altogether. I have no problem with developers who clearly understand XSD/WSDL, along with the corresponding System.Web.Services attributes, but choose to adopt a code first process for productivity sake throughout an org (along with prescribed best practices of course). This is simply not common from what I've seen. Instead they do it because ignorance is bliss.
Regardless of which approach you choose, when you have to fix a leak, you'll be forced to deal with what's on the wire. Obviously this is more approachable for developers who are familiar with XSD/WSDL and who started by designing things in those terms. If nothing else, adopting a contract-driven process within an organization encourages filling this crucial knowledge gap.
Unfortunately, this discussion has can't seem to move away from generalizations, which makes it difficult for casual spectators to measure the pros and cons of the different models given their particular problems. I firmly believe that there are specific situations where a contract-driven approach is the only practical way to design and successfully build SO systems. But I think that horse is officially dead.
Posted
Apr 27 2005, 05:44 PM
by
Aaron Skonnard