WCF sam zapewnia mapowanie wszystkich typów prostych .NET na elementy SOAP-a. Dlatego też nie ma problemu z parametrami prostymi, tablicami, a nawet kolekcjami generycznymi z typów prostych. W przypadku wykorzystania typów złożonych mamy dwa sposoby na sprawienie, aby nasz typ złożony mógł być mapowany. Pierwszym jest oznaczenie typu poprzez atrybut Serializable (i sprawienie, aby był serializowalny), drugim sposobem atrybut DataContract, którym teraz się zajmiemy.

W zasadzie można jeszcze obejść ten problem w jeden sposób. Mianowicie można zastosować parametr typu Message, który umożliwi nam bezpośredni dostęp do wiadomości SOAP. Tak, więc chcąc poznać pewne wartości, wówczas będziemy analizować XML-a. Wówczas nie będzie dochodzić do serializacji danych, jednak na dobrą sprawę my ręcznie będziemy musieli to zrobić. Może mieć to zastosowanie w sytuacji, gdy serializacja jest zbyt kosztowna, jednak w dokumentacji jest odradzane odnoszenia się w kodzie do wiadomości SOAP.

Tak, więc na pomoc nam idzie atrybuty DataContract i DataMember. DataContract jest atrybutem oznaczającym typ złożony, który ma być przesyłany w wiadomościach SOAP przez WCF. Jako parametry ten atrybut może przyjąć nazwę i przestrzeń nazw, które będą użyte w wygenerowanym XSD. DataMember może być stosowany zarówno do pól, jak i do własności (ang. property) oznaczają typy, które mają być mapowane na SOAP. Nie wszystkie pola/własności muszą być przesyłane w wiadomości. Przez ten atrybut możemy ustalić następujące rzeczy:

a) Nazwę i przestrzeń nazw

b) Oznaczenie, czy pole jest wymagane - jednak nie dotyczy to wartości, tylko obecności tych elementów w przesyłanej wiadomości SOAP. Ma to duże znaczenie przy wersjonowaniu serwisów.

c) Kolejność pól/własności w XSD

d) Wartość domyślną

Poniżej zamieszczam przykład zastosowania DataContract:

[DataContract()]
    class Post
    {
        [DataMember(IsRequired = true, Order=2)]
        public string message;
 
        [DataMember(IsRequired = true, Order=1)]
        private string title;
 
        private string userName;
 
        [DataMember(IsRequired = true, Order=0)]
        public string UserName
        {
            get
            {
                return userName;
            }
            set
            {
                userName = value;
            }
        }
    }

Warto tu zaznaczyć, że niezależnie, czy pole ma modyfikator private czy public, jest traktowane tak samo i u klienta będzie wyglądało tak samo. Przy generowaniu kodu przy pomocy svcutil jest tworzony typ taki jak oznaczony DataContract w serwisie, jednak wszystkie pola są z modyfikatorem private i mają dopisane własności z dostępem do pól. Tak więc, domyślnie jak wszystkie pola, będzie można modyfikować.