.NET 3.5 SP1 and WCF coding guidelines

I am curious if POCO support for data contracts in .NET 3.5 SP1 affected coding guidelines. In brief, prior to .NET 3.5 SP1 all data structures that were part of WCF service contracts had to be decorated with DataContract attributes, and in order for their fields to be handled by DataContractSerializer they had to be decorated with DataMember attribute. Latest .NET service pack relaxed this requirement, so now if a class is not marked as DataContract, then all its public properties will be serialized. These two definitions are now equivalent assuming their namespace names match:

[DataContract]
public class Customer : IExtensibleDataObject
{
    [DataMember]
    string FirstName { get; set; }

    [DataMember]
    string LastName { get; set; }

    public ExtensionDataObject ExtensionData { get; set; }
}

public class Customer : IExtensibleDataObject
{
    public string FirstName { get; set; }

    public string LastName { get; set; }

    public ExtensionDataObject ExtensionData { get; set; }
}

More on WCF serialization programming model.

I checked Juval Lowy’s updated WCF coding standard, and here is quite clear on this subject: “avoid inferred data contracts (POCO). Always be explicit and apply the DataContract attribute.

I can see his point now when .NET classes used in WCF service contracts represent a small fraction of all classes defined in the system. It is similar to early COM years when developers had to place COM interfaces and classes in dedicated IDL files and use MIDL compiler to generate proxy/stub libraries. Now every .NET object is essentially a COM object, and Juval himself predicts that advantages of WCF programming model will eventually make developers write most of their classes as WCF contracts. And the changes in .NET 3.5 SP1 proves that Microsoft wants this transition to be smooth and removes restrictions that prevented standard .NET types to be treated as WCF contracts. So I am not sure which coding standard I would choose today: the one based on a principle “boundaries are explicit” or the one that provides POCO and WCF with unified syntax.

One thought on “.NET 3.5 SP1 and WCF coding guidelines”

  1. Another reason for not returning DataReader, DataTable and DataSet from a service or from a DAL (for that matter) is that it is a Leaky Abstraction. You’re exposing/leaking the data storage details to the calling clients or to the upper layer like the business layer.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>