[
Lists Home |
Date Index |
Thread Index
]
Aaron Skonnard wrote:
> How well the "back end" deals with exceptional conditions is
> implementation dependent. For example, if you write a Web service in
> .NET like this:
>
> [WebMethod]
> public double Add(double x, double y) {
> return x+y;
> }
>
> It expects an Add element with two child elements, x and y. If, however,
> you send it an Add element with foo and bar child elements, or no child
> elements, or something else off the wall, it will happily return 0. This
> is a false positive, where most developers would expect an exception.
> Performing schema validation before the method is called moves such
> error handling down a layer and protects you from this type of thing
> happening.
There are some controversial design choicesin the above, but the
argument for schema validation because it pushes some things down a
layer does have some merit.
But I don't buy it. If I'm going to be accepting transactions encoded
in XML my *business* level validation is going to be doing a lot of
looking up part numbers in catalogues and buyer-IDs in other databases
and pricing rules and so on and so on. If I'm already doing this in a
high-volume transaction processing application I think it's going to be
hard to justify a full-dress schema validation step when the
business-validation code already knows the data types and can do the
data conversion right down there inline, and fail deterministically if
something isn't as expected. -Tim
|
