DataMember Best Practices
I was asked to share a list of best practices I wrote for data contracts and data members so here it is:
-
Do apply the DataMember attribute only to properties rather than the corresponding fields.
-
Do not use type inheritance to version a data contract. Either modify the existing type or create an entirely new type.
-
Do not add or remove enumeration members between versions.
-
Do not change the name or namespace of a data contract or data members between versions.
-
Do not change the order of data members between versions.
-
Do set the IsRequired property to false on data members added in later versions.
-
Do not remove data members in later versions even if they are marked as not required.
-
Do support IExtensibleDataObject on data contracts to support future compatibility with extended types.
-
Do apply the DataMember attribute only to public members. Serialization of private data members is not supported for partial trust environments.
-
Do not rely on constructor visibility, constructor link demands, constructor security actions, or validation checks in the constructor to make a DataContract type safe for partially trusted callers. DataContractSerializer does not invoke the constructor when initializing an object.
Next time: Using Call Context Initializers for Cleanup
