How to check WCF data element skipped in XML? - wcf

Question

In my WCF I defined an object "Product" as below:
<xs:complexType name="Product">
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="Postcode" type="xs:string" nillable="true" minOccurs="0"/>
<xs:element name="ProductID" type="xs:string" />
</xs:sequence>
</xs:complexType>
Please note the element "Postcode" is nillable="true" minOccurs="0", this means when client application call the web service, they can either provide empty value for this element as below:
<Product>
<Name>Product 1</Name>
<Postcode></Postcode>
<ProductID>10</ProductID>
</Product>
Or they can simple skip "Postcode" element so the incoming message becomes this (Postcode isn't there)
<Product>
<Name>Product 1</Name>
<ProductID>10</ProductID>
</Product>
My question is, in my host program how do I check if the element "Postcode" exists in the incoming XML message? I am asking because if it doesn't there and I call the method to get Postcode value, then the program will throw an error:
string postcode = product.Postcode - this call will throw an error?
Thank you all very much for any ideas/suggestions.
Charles

Answer 1

You are not correct in your assertion that using nillable in your definition permits the two cases you have listed.
In fact, the nillable xsd attribute permits the construction:
<Postcode xsi:nil='true'/>
which is semantically different from Postcode being either empty, or just not present at all.
In answer to your question,
how do I check if the element "Postcode" exists in the incoming XML
message
I don't quite understand why you want to define Postcode with minOccurs=0. When wcf receives this type across the wire it will attempt to deserialise to a predefined C# type. In C#, types either have properties or they don't have.
eg.
public class Product
{
public string Postcode { get; set; }
}
is not the same things as
public class Product
{
}
So by allowing callers to construct two different versions of your Product type you are actually forced to define two separate C# types to deserialise to, which means you'll need to expose your service operation twice, once for callers who want to use Product with postcode, and one for those who want to use Product without.
I would suggest that you redefine your Product type to include the Postcode element - after all because it's a string your callers can just leave it null if they do not wish to use it.