WCF - Instantiating an object in DataContract constructor - wcf

Question

I have two classes as below:
[DataContract]
public class Address
{
[DataMember]
public string Line1
[DataMember]
public string Line2
[DataMember]
public string City
[DataMember]
public string State
[DataMember]
public string Zip
}
[DataContract]
public class Customer
{
public Customer()
{
CustomerAddress = new Address();
}
[DataMember]
public string FirstName
[DataMember]
public string LastName
[DataMember]
public Address CustomerAddress
}
What will happen if i generate proxy of my service that uses Customer class? If i understand the concept correctly then i think the constructor in the Customer class will not be called at the client side and it may give different behavior.
How do i get rid of that constructor in the Customer class and still have the CustomerAddress property of type Address so that it behaves as a dumb DTO object?
What is the general guideline or best practices that people use to avoid this situation?

Answer 1

If you use the default DataContractSerializer to serialize your objects, then, yes, your constructor is not serialized, and any logic you may have in it will not be called by your client when the object is deserialized.
Regarding your question about removing the constructor logic and having the nested Address class be populated, that will be taken care of by the DataContractSerializer. If I have code like this:
Customer c = new Customer() {
FirstName = "David",
LastName = "Hoerster",
CustomerAddress = new Address() {
Line1 = "1 Main Street",
City = "Smallville",
State = "AA",
Zip = "12345"
}
};
and then return that from a service method, that Customer object will be serialized properly along with the Address information. The proxy on the client that's generated will know about Address and will be able to deserialize the stream coming from the service method to properly construct your Customer object. Your Customer will be a dummy DTO -- no logic, just properties.
Check out Aaron Skonnard's MSDN article on WCF Serialization where he talks about the DataContractSerializer.

Answer 2

If you generate the client (using svcutil or "add service reference"), then the generated DataContract will look like:
[DataContract]
public class Customer
{
// empty default constructor
public Customer()
{
}
[DataMember]
public string FirstName
[DataMember]
public string LastName
[DataMember]
public Address CustomerAddress
}
Your implementation details are not carried over. All that is generated is what goes into the WSDL, which is just the [DataMember] properties in this case.
I mention this because your original question asks: "What will happen if i generate proxy".
If this is an object being sent from the server to the client, then you can just always initialize CustomerAddress before sending it to the client. Infact, if your original code is on the server, then that constructor will be run, and WCF will serialize the CustomerAddress and basically never send a null (unless you set it back to null after the constructor).
If you want to make it so that the client always sends you a CustomerAddress, then you could:
have the server check for null, like if(x.CustomerAddress == null) x.CustomerAddress = new Address();
mark the DataMember as required, then the server will return an error if the client did not pass anything: [DataMember(IsRequired=true)] public Address CustomerAddress;
Otherwise, I don't think there is any way to force the generated WCF client to initialize that field for you.

Answer 3

You'd better define all the data contract classes in a assembly and have both server project and client project reference to the assembly so the initialization behaviour can be shared. When generating service reference, you can instruct the code generator to use existing data contract classes.