I have some services at the moment that return a dto with the following fields:
[DataMember]
public int Id { get; set; }
[DataMember]
public string Name { get; set; }
and I want to add more to this service by adding the following properties:
[DataMember]
public virtual DateTime StartDate { get; set; }
I'm not in a position where i can update the consumers of these services though - the client does that themselves.
My开发者_JAVA百科 question is - will the old clients be able to just skip these new properties? and the new ones take advantage of them or will the serialization be an issue with the new properties?
w://
As long as the old properties do not change (and the new one is marked as optional) you should be alright.
Said so, you should publish the new contract and get the clients to regenerate the service reference - or deploy the new version to a different endpoint so that when they're ready to switch they are forced to point to the new one.
From what I have seen, the DataContractSerializer just puts null in for properties not found when deserializing. Makes tracking down some bugs quite tricky - sometimes I would prefer if it were more strict and gave an exception.
Another option to consider is subclassing the original DTO to create a new derived class.
In order for serialization to work properly, you need to specify the available derived classes for the supertype with an attribute:
[DataContract]
[KnownType(typeof(DerivedDTO))]
public class OriginalDTO
In code where you use the additional property, you will need to cast the object to a DerivedDTO to get access to the property (I use the as keyword for this and check whether the resulting reference is null before using it)
As long as the new member StartDate
is not declared a required field - so this would not work:
[DataMember(IsRequired="True")]
public virtual DateTime StartDate { get; set; }
But as long as you leave out the IsRequired=True
, you should be fine.
精彩评论