Which serialization control declaration flavor do you like?

I’ll write a few more parts of my little Indigo series next weekend (too busy during the week), and will move from “throw arbitrary XML on the wire” to typed messages. However, before I’ll do so, I am curious about your opinion and I am asking you to comment (on the blog-site) on which of the following two declarations you would prefer.

I should probably quickly explain a few things before I let you look at the code snippets: [DataContract] attribute essentially replaces [Serializable] for Indigo and is used to label classes than can be serialized by the System.Runtime.Serialization infrastructure into XML or into a binary representation. So the serialization control through attributes is unified and independent of the actual output flavor you choose at runtime. The [DataMember] attribute labels fields or properties that are part of the data contract and should be (de)serialized. Unlike the current serialization models of Remoting (System.Runtime.Remoting.Formatters) and the XML Serializer (System.Xml.Serialization) where the serializers grab anything public, this model is strictly opt-in, meaning that public fields and properties do not get serialized unless you explicitly label them with [DataMember]. Even more surprising, the new serialization infrastructure does work with fields that are private.

I have a clear preference for one of these two declarations and have also what I think to be a solid explanation for why I prefer it, but before I elaborate, I am interested in your opinion.

Version A

[DataContract]
public partial class Address
{
    [DataMember("Company")]
    private string company;
    [DataMember("RecipientName")]
    private string recipientName;
    [DataMember("AddressLine1")]
    private string addressLine1;

    ... more fields ...

    public string Company
    {
        get { return company; }
        set { company = value; }
    }

    public string RecipientName
    {
        get { return recipientName; }
        set { recipientName = value; }
    }

    public string AddressLine1
    {
        get { return addressLine1; }
        set { addressLine1 = value; }
    }

    ... more properties and methods and stuff ...
}

Version B

[DataContract]
public partial class Address
{
    private string company;
    private string recipientName;
    private string addressLine1;

    ... more fields ...

    [DataMember("Company")]
    public string Company
    {
        get { return company; }
        set { company = value; }
    }

    [DataMember("RecipientName")]
    public string RecipientName
    {
        get { return recipientName; }
        set { recipientName = value; }
    }
    [DataMember("AddressLine1")]
    public string AddressLine1
    {
        get { return addressLine1; }
        set { addressLine1 = value; }
    }

    ... more properties and methods and stuff ...
}

Consider this obvious statement: The class is declared in this way to provide programmatic access to and encapsulation of data that will eventually be serialized into some wire format or deserialized from a wire format.

Clemens Vasters