When svcutil.exe is used to generate the proxy for a WCF service, it creates a copy of the service contract (interface) and the data contracts used by that service contract. If you use the DataContractSerializer on the service (the default option), you are implying that you want to share the contracts and not the types so the copy of the data contract created by svcutil.exe only includes the fields and properties decorated with DataMemberAttribute and does not include other members of the type like the constructors. This means that any additional constructor(s) you may have created for the data contract on the server side will not be present on the client.
So how should we design our application if we want to use the constructors on the client side? Typical consulting answer: "It depends".
- If you want to have a constructor with the same signature and implementation on the client, then sharing the types is an option. You can share the types by adding a reference to the assembly containing the data contract. You can then instruct svcutil.exe to use the referenced types instead of creating copies of those types using the /reference option (which is the default behaviour when you use "Add Service Reference" in Visual Studio). You need to understand that sharing the types will result in type fidelity and you will need to change the data contract on both sides every time you modify it. If you are building a service-oriented application, then you should try to avoid sharing the types as it does not follow the "Share the contract, not the type" tenet of service orientation.
- If you want to have one or more constructors on the client side but these constructors are not the same as those available on the server side, you can use svcutil.exe to generate the copy of the data contract on the client and then add the constructors you need on the client side. If you look at the type definition for the data contract svcutil.exe generates on the client, you will notice that it is marked as partial. So you can create a new file and define the constructors you want to add to the partial class. Note that you should not make any modifications to the generated class as you will lose your changes when you regenerate the class and in fact, this is one of the main reasons why partial classes are supported by the compilers.
Something that you need to be aware of is that the parameter-less constructor for the data contract is only called when the object is instantiated by your code. So for example, when you call a WCF service and the service returns a data contract, WCF runtime on the client side does not call the parameter-less constructor, which makes sense as the returned message includes all the state you need and there is no point in running the constructor. If you need to perform an operation when the message is received by the client, you can use OnDeserializingAttribute or OnDeserializedAttribute defined in System.Runtime.Serialization namespace.
In order to see how this works, let's have a look at an example. The Customer class is a data contract defined on the server side. It has one constructor that takes the customerId as the parameter.
We don't need any other constructor on the server side as the only place we need to instantiate the Customer class is in GetCustomer operation and the Customer object is passed into the rest of operations.
As we mentioned earlier, svcutil.exe does not generate any constructors on the client side but what we can do is to create a file that adds the required constructors to the data contract, which is defined as a partial class. The following code segment shows how to add the additional constructor to the partial class. We have also added two methods that are decorated with serialization attributes, which we will talk about later in this post.
The constructor on the client side takes a string parameter instead of int as the client knows about the name of the new customer but not their ID. The following code segment shows how we can use this constructor on the client side:
This is one of the benefits of a shared contract design as we can define a different constructor on the client side to suit the specific needs of the client application.
We mentioned that WCF does not call the constructor when the Customer object is deserialized so we need to use the serialization attributes if we want to perform an initialisation operation. In this case, we want to make sure that the client application does not change the ID for an existing customer so we record the original customer ID when the Customer object is received by the client and compare the ID property with the original value when it is being serialized and before it is sent back to the server.
So it is important to understand the difference between the constructors and the methods decorated with serialization attributes. The constructors are called when you create instances of the data contracts in your code whereas the decorated methods are called by the WCF runtime before (or after, depending on the attribute you are using) the data contract object is received/sent by a party in WCF.
Sample code download: