C# using the Order property of DataMember attributes

[Markbnj]

The iOS app that I'm working on exchanges messages with a set of WCF REST services implemented in C#. I ran into a problem where elements of a request body were not being deserialized correctly to properties on the service side, i.e. one property was coming through and the others were null. After confirming the contents of the request itself I took a look at the entity, and noticed that the previous developer has declared the members like this...

[DataMember(Order = 0)]
int SomeProperty { get; set; }

[DataMember(Order = 1)]
int AnotherProperty { get; set; }

I had never used this property of the DataMember attribute, but a survey showed that it was used in all the contract entities for this app. The MS docs are a little ambiguous. They say the property may be used to specify the order of deserialization where that order is important. So presumably the elements will be deserialized in the order you specify, but are you adding that ordering to the contract, i.e. the XML request must follow that order?

I wasn't sure, but I did see that the client was not constructing the XML in the specified order. I removed the Order properties from the member declarations and it started working. So I guess that answers that.

I asked the other developer about it and he gave me an explanation that wasn't very convincing, i.e. it was done so the client would know exactly what order to use and expect. But from my perspective the whole point of XML is that I shouldn't have to worry about the specific ordering of elements, just their type and their hierarchical relationships. Why do I care what order a bunch of sibling elements are deserialized in? It seems to me that the use of the Order property in this context imposes an arbitrary ordering dependency on the XML and increases the fragility of the message protocol.

However, before I change it all I wanted to get some other reactions. Is there some reason why using Order would ever make sense when deserializing XML?

 

[Train]

the only reason I can think that the order would be important is if a member is dependent on the value of another member and you want to avoid setting them in an incorrect order during an initialization phase (something that would be handled by a constructor under normal instance initialization)

I have never seen the order attribute, it seems similar/redundant to the ByteOffset attribute, which can be used as an equivalent to C++'s union feature, and has come in handy quite a few times.

I would look at the XML serialization output to look for reasons why an order might be important. Perhaps there is something neither of us is thinking of.

 

[Markbnj]

I can't see any order dependencies at all. On the deserialization side the client uses NSXmlParser, which is event driven. So you get callbacks on each element it finds, parse the name and value, and set the property. No dependencies between elements that I can see.

 

[KB]

I can't think of any reason why order would be important unless the service was being consumed by a non .Net client that only saw the data as XML and not as objects. Then the order might be important if the developer was lazy and decided to reference nodes using indexers instead of name.

i.e
xmldocument.DocumentNode.ChildNodes[1].innerText

 

[Markbnj]

Yeah that was my take on it as well, KB. The client is in fact consuming the raw xml (custom deserialization) but it references all nodes by name. Think I am going to clean the entity defs up to remove the order definition.