Yan Cui
I help clients go faster for less using serverless technologies.
This article is brought to you by
MongoDB 8.0 is here to change the game. Faster reads and inserts, and brand-new vector search to support modern AI-powered apps.
One of the less known aspect of the DataContractSerializer is its dependency on the order in which fields are serialized and deserialized.
As this article points out, the basic rules for ordering include:
- If a data contract type is a part of an inheritance hierarchy, data members of its base types are always first in the order.
- Next in order are the current type’s data members that do not have the Order property of the DataMemberAttribute attribute set, in alphabetical order.
- Next are any data members that have the Order property of the DataMemberAttribute attribute set. These are ordered by the value of the Order property first and then alphabetically if there is more than one member of a certain Order value. Order values may be skipped.
The problem is that when the inbound data is not ordered accordingly the fields which are ‘out of order’ will not be deserialized as highlighted by this StackOverflow question. Though this is unlikely to happen as the serializer will take care of the correct ordering for you, unless like jhersh you are attempting to manually create some data for test purposes.
Parting Thoughts…
Seeing as the DataContractSerializer is also dependent on the ordering of the fields in the serialized type (albeit not transparent to you and well taken care of almost all the time) I have long been tempted to try out the Protocol Buffers wrapper for .Net which are meant to be much faster and more compact because it doesn’t serialize the names of the properties unlike the DataContractSerializer.
For those of you who aren’t aware of it, protocol buffers is the binary serialization used by Google for most of its data communications. In order to use the protobuf-net serialization you need to explicitly specify the order in which your properties should be serialized:
[DataContract] public sealed class Test1 { [DataMember(Name="a", Order=1, IsRequired=true)] public int A { get; set; } } [DataContract] public sealed class Test2 { [DataMember(Name = "b", Order = 2, IsRequired = true)] public string B { get; set; } } [DataContract] public sealed class Test3 { [DataMember(Name = "c", Order = 3, IsRequired = true)] public Test1 C { get; set; } }
And inject a new behaviour to the WCFmethod to use the new serializer:
[ServiceContract] public interface IFoo { [OperationContract, ProtoBehavior] Test3 Bar(Test1 value); }
Oh, such temptation…
References:
StackOverflow question – WCF data contract, some fields do not serialize
Whenever you’re ready, here are 3 ways I can help you:
- Production-Ready Serverless: Join 20+ AWS Heroes & Community Builders and 1000+ other students in levelling up your serverless game. This is your one-stop shop for quickly levelling up your serverless skills.
- I help clients launch product ideas, improve their development processes and upskill their teams. If you’d like to work together, then let’s get in touch.
- Join my community on Discord, ask questions, and join the discussion on all things AWS and Serverless.