Data Contract Hierarchy
Your data contract class may be a 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 CustomerNumber;
}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 attributes in the class
hierarchy:
[Serializable]
class Contact
{...}
[DataContract]
class Customer : Contact
{...}However, the Serializable
attribute will typically be at the root of the class hierarchy, if it
appears 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 you
make use of the subclass in a service contract:
[ServiceContract]
interface IContactManager
{
[OperationContract]
void AddCustomer(Customer customer); //Contact is exported as well
...
}Known Types
In traditional object-oriented programming, a reference to a subclass is also a reference to its base class, so the subclass maintains an Is-A relationship with its base class. Any method that expects a reference to a base ...