Question

Im am not new to WCF web services but there has been a couple of years since the last time I used one. I am certain that last time I used a WCF service you could determine the type of object returned from a service call when developing the code. EG;

MyService.Models.ServiceSideObjects.User user = myServiceClient.GetUser();

You were then free to use the ‘user’ object client-side. However now it seems as if the WCF service will not return anything more than objects containing basic value types (string, int ect). So far I have remedied this by defining transfer objects which contain only these basic value types and having the service map the complex ‘User’ objects properties to simple strings and int’s in the transfer object.

This becomes a real pain when, for example you have custom type objects containing more complex objects such as my Ticket object.

public class Ticket
{
    public Agent TicketAgent {get;set;}
    public Client Owner {get;set;}
    public PendingReason TicketPendingReason {get;set;}
}

As simply mapping this object graph to a single transfer class with a huge list of inter-related system-typed properties gives a very ‘dirty’ client-side business model. Am I wrong in thinking that I SHOULD be able to just receive my Ticket object from a service method call and deal with it client side in the same state it was server-side ?

I realise this is probably a violation of some SoA principal or similar but my desktop app currently consuming this service is the ONLY thing that will consume ever consume it. So i do not care if many other clients will be able to manage the data types coming back from the service and therefore require some hugely normalised return object. I just want my service to get an object of type Ticket from its repository, return this object to the client with all its properties intact. Currently all I get is an object with a single property ‘ExtentionData’ which is unusable client-side.

Hope this makes sense, thank you for your time.

Answer 1

I might’ve missed a memo, but I think you need to decorate your model classes with DataContractAttribute and your properties with DataMemberAttribute, like so:

[DataContract( Namespace = "http://example.com" )]
public class Ticket
{
    [DataMember]
    public Agent TicketAgent { get; set; }

    [DataMember]
    public Client Owner { get; set; }

    [DataMember]
    public PendingReason TicketPendingReason { get; set; }
}

This is why you probably want to set up a DTO layer, to avoid polluting your model classes.

As for ExtensionData, it’s used for forward-compatibility: http://msdn.microsoft.com/en-us/library/ms731083.aspx