Please, keep the [DataContract] attrubute only, you don't need decorating with Serializable as well.
Well, one have the following options with WCF Data Contracts:
Composite Data Contracts.
Member fields of any class marked as DataMember can be data contracts themselves, once they're decorated with DataContract attribute too. Aggregation of all nested data contracts illustrates the fact that data contracts are recursive in nature. WCF detects all the data contract enabled properties in the object graph and captures their state as well.
[DataContract]
class Address
{
[DataMember]
public long AddressId { get; set; }
}
// The same for the rest two, and then an aggregating type.
[DataContract]
class Contact
{
[DataMember]
public Address Address {get;set;} // here we go
[DataMember]
public Email Email {get;set;}
[DataMember]
public Phone Phone {get;set;}
}
Data Contract Hierarchy
Your data contract class may be a subclass of another data contract class, here you just have to explicitly opt-in for a given data contract, i.e. specify the DataContract on each type in the hierarchy tree.
[DataContract]
class ContactDetails
{
[DataMember]
public long AddressId { get; set; }
// you could move the phone and email details here too.
}
[DataContract]
class Contact : ContactDetails
{
[DataMember]
public string Name { get; set; }
}
You can't have three separate classes for each one and inherit from them at once in .Net. And my suggestion is the first case for you - that is data contract aggregation.
Bonus: Polymorphic Type Reference.
Applying the [KnownType(Type type)] attribute on a base type for passing polymorphic objects as operation contract arguments. This is definately not your case.