DataContracts and DataMembers

Are there any ways to tell WCF to serialize the whole class when it returns? Do I literally have to ad开发者_运维技巧d DataMember to every property?

Since .NET 3.5 SP1, you don't have to do this anymore.

If you don't have any [DataContract] and [DataMember] attributes, the DataContractSerializer class will behave like the old XmlSerializer: it will serialize all public read/write properties that are listed in the class.

You do lose a few things in the process though:

• since you don't have [DataMember] attributes, you cannot define an order of the fields anymore - they'll be serialized in the order of appearance

• you cannot omit a public property (since that would require [DataMember] on all other properties/fields)

• you cannot define a property to be Required (that would be on the [DataMember] attribute again)

• your class now needs to have a public, parameter-less constructor (usually not needed for data contracts)

Read all about it in detail from Aaron Skonnard at Pluralsight.

I love marc's answer, but I want to add some more info.

DataContractSerializer and DataContractJsonSerializer both support, out of the box, many other serialization models as well. This includes IXmlSerializable, Serializable, and ISerializable. POCO support was added in .NET 3.5 SP1, but support for these other models has always been there since .NET 3

This blog post details the extent of the support and more importantly, the prioritization of different models by the serializer (i.e., it tells you what DataContract-based serializers would do if you have one type decorated with multiple serialization models)

So, if you read that blog post, you'll notice that POCO support is last in the priority list. It is the serializer's last resort, if there is absolutely no other serialization programming model available on the type or its parent. For example, if the type is an enumerable of some sort, it will get serializaed according to traditional collection rules. If it's ISerializable or Serializable, it will get serialized according to their serialization rules.

Another important difference: during deserialization of all other types, the default zero-params constructor is never called. For POCO types, it is always called! This gives you an additional hook you don't have so easily in other serialization models!