Programming WCF Services

Data Contract Hierarchy

Your data contract class may be the subclass of another data contract class. WCF requires that every level in the class hierarchy explicitly opt in for a given data contract, because the DataContract attribute is not inheritable:

[DataContract]
class Contact
{
   [DataMember]
   public string FirstName;

   [DataMember]
   public string LastName;
}[DataContract]
class Customer : Contact
{
   [DataMember]
   public int OrderNumber;
}

Failing to designate every level in the class hierarchy as serializable or as a data contract will result in an InvalidDataContractException at the service load time. WCF lets you mix the Serializable and DataContract attribute in the class hierarchy:

[Serializable]
class Contact
{...}

[DataContract]
class Customer : Contact
{..}

But typically the Serializable attribute will be at the root of the class hierarchy, if at all, because new classes should use the DataContract attribute. When you export a data contract hierarchy, the metadata maintains the hierarchy, and all levels of the class hierarchy are exported when making use of the subclass in a service contract:

[ServiceContract]
interface IContactManager
{
   [OperationContract]
   void AddCustomer(Customer customer);//Contact is exported as well
   ...
}

Known Types

While languages such as C# let you substitute a subclass for a base class, this is not the case with WCF operations. By default, you cannot use a subclass of a data contract class instead of its base class. Consider this service contract:

[ServiceContract] ...