Vagif Abilov's blog on .NET

.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.

Comments

SamLazy said:

Interesting, he does not recommend passing or returning DataSets. Sometimes using DataSet can reduce development time for example binding in ASP.NET. I don't like DataSets myself but I admit it can simplify development.

# April 4, 2009 3:02 PM

Vagif Abilov said:

I must admit I lost my faith in DataSet long time ago (or did I ever have it?) You can bind ASP.NET controls directly to custom objects or collections, and it will reduce memory footprint a lot.

But another reason why DataSet/DataTable is not recommended to be used in service contracts is that they are platform specific. Why limit your potential clients just to those who use Visual Studio?

# April 4, 2009 3:29 PM

SamLazy said:

I agree with that.

But I've seen projects with huge DataSets flying from/to services and my attempts to change that didn't meet understanding.

# April 4, 2009 4:10 PM

An Phu said:

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.

# April 15, 2009 9:06 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Please add 5 and 6 and type the answer here: