WCF DataMember attribute for read-only fields?

Question

I am trying to create a class with a read-only Id field, however I am having problems retaining the value when the object passes through the WCF server.

I cannot set the [DataMember] attribute on the public property since there is no set method, and I would like to keep it that way if possible since I do not want this value changed by external means. I cannot set the [DataMember] attribute on the private field since it throws an error in partial trust environments.

public class MyClass
{
    private int _id;

    public int Id 
    { 
        get { return _id; } 
    }

    private string _otherProperties;

    [DataMember]
    public string OtherProperties
    {
        get { return _otherProperties; } 
        set { _otherProperties = value; }
    }
}

Is there a way to maintain the value of the Id field while going through the WCF server without making my property public?

Palinode

msdn.microsoft.com/en-us/library/ms733127.aspx : It should not throw an error if you have a private method. You can see in the note : that DataContract does not care about the visibility of method. – Annabell

Answer 1

Generally speaking, your data contract classes should be very lightweight data transfer objects without any logic or deeper meaning attached to them. Just containers to ferry data across the cloud. They should be public classes, with just a set of public read-write properties. In your business logic classes, you should convert these into some internal business entities and do the reverse when transmitting data.

This separates the data transfer model from any internal entity model and ensures optimal maintainability, allowing you to avoid problems such as the one you are facing - where OO design issues conflict with WCF operating behavior.

With very small projects the overhead of keeping a separate model might not be worth it. AutoMapper can be of some help minimizing the manual labor required.

Speaking of your specific scenario, I am not sure I exactly understand the problem statement. You do not want some field to be modified? But this field is just a part of the data model - parts of the data model are never "modified" - there is no "old" data, just data your client makes up. Your client code just sends a data object to the server. If the server does not care about one member of the class, it should just ignore it.

It's not like instnaces of the data contract objects exist on the server and wait for clients to manipulate them. A read-only field might conceptually make sense in such a scenario but this is not so with WCF. The client just makes up an object and sends it to the server. If you do not want the server to listen to some data, either do not add it to the data model or (if perhaps it is sometimes needed, only for specific users or such) make the server ignore it when it is not desired.

Testee

Let me see if I have this straight... you're suggesting each object should have two parts: a DataTransfer (DataContract) class for sending/receiving data to/from the WCF server and the actual class itself which contains the business logic, INotifyPropertyChanged, functionality, etc? – Palinode

Yes and no. The data transfer objects need not actually map one-to-one to any business logic objects. For example, I might have a large and complex Employee business object but over my various WCF operations, I just expose the data relevant to the particular operation. E.g. UpdateContactInfo(Guid employeeID, ContactInfo info) would only carry the contact info - while it might still be a part of my Employee business object. For small scenarios the data transfer object and business object tend to be almost identical, though - just without any "undesirable" fields (e.g. password hash). – Testee

Answer 2

You can do this:

public int Id
{
     get;
     private set;
}

This will keep the deserializer happy, while not letting people actually set the ID value. You'll have to set it in the constructor, or in the setter of another property.

However, I do agree with Sanders, in that your DTO should be a dumb container.

Kittle

Answer 3

No. Data member has to have getter and setter to be serializable. It is service responsibility to validate that Id was not changed on the client.

Elvera