3

I am wondering if I am missing anything here... My understanding is that I should be able to get the ID property (but not set it) after deserializing. As it stands, the ID property is not brought along at all:

namespace CableSolve.Orders.Core.Dto
{
    [Serializable]
    [XmlRoot("Task"), SoapType("Task")]
    public class TaskDto : IDto
    {
        // ReSharper disable ConvertToAutoPropertyWithPrivateSetter
        private int _id;
        public int ID { get { return _id; } }
        // ReSharper restore ConvertToAutoPropertyWithPrivateSetter
        public int TaskSequence { get; set; }

        public TaskDto()
        {
        }
    }
}

Ideally my ID would not be settable. If I give the ID property an automatic, private setter -- XML Serializer throws a fit. I thought the workaround for that was described here, but it does not appear to work for non-collections? I would prefer to not have to rewrite using DataContract at this point in time.

'CableSolve.Web.Api.WorkflowServicesProxy.TaskDto' does not contain a definition for 'ID' and no extension method 'ID' accepting a first argument of type 'CableSolve.Web.Api.WorkflowServicesProxy.TaskDto' could be found

Sean Anderson
  • 27,963
  • 30
  • 126
  • 237
  • I'm assuming the Dto here means this is your Data Transfer Objects library. If that's the case then why don't you want a setter for your property? In this case it would be necessary for Deserialization. – HasaniH Sep 12 '12 at 22:06
  • It's the ID field of an object representing an entry in a DB. I'm not sure why we would want this modifiable. Bad things would happen if the user modified a Task's ID property and then called Save -- it would overwrite another Task's properties in the DB. – Sean Anderson Sep 12 '12 at 22:13
  • Naturally, that's why it should only be modifiable in your DTO library. Not for the user to modify but for the XmlSerializer to modify during deserialization. Once the DTO object is constructed (in your data transfer layer) you create an instance of the actual object it represents. This instance has ID as a read only field and is accessible to user code. That's the idea behind the DTO design pattern. Your DTO objects aren't for user manipulation they are strictly for data transfer. – HasaniH Sep 13 '12 at 00:02
  • possible duplicate of [Why are properties without a setter not serialized](http://stackoverflow.com/questions/13401192/why-are-properties-without-a-setter-not-serialized) – nawfal Jul 11 '14 at 20:13

1 Answers1

3

The deserialiser is just C# code. It requires a setter for a serialised property. Thus you must have a getter and setter for every property that is to be serialised by XML serializer; it also requires the property to be public.

Also you do not need an empty constructor for the class.

[Serializable]
[XmlRoot("Task"), SoapType("Task")]
public class TaskDto : IDto
{
    public int ID { get; set; }
    public int TaskSequence { get; set; }
}

For more info, see http://msdn.microsoft.com/en-us/library/system.xml.serialization.xmlserializer.aspx

Richard Schneider
  • 34,944
  • 9
  • 57
  • 73