tags:

views:

35

answers:

4

Are DataContracts in WCF nothing more than DTOs? I was reading up about WCF and just had a couple of thoughts. It would be nice if some of the DataContract objects could have methods on them so that the client could do basic things with them before or after sending or retrieving back to the service.

To me this just doesn't seem possible or logical. I could be wrong, I learn new things everyday. So would the next best thing be to treat DataContracts as DTOs and provide libraries for the clients that would create real objects from the DTOs. Objects that would contain methods.

Any guidance would be really appreciated.

+3  A: 

Not sure if I correctly understood your answer, so correct me if I'm wrong.

You can create a class library with your DataContracts classes and share the library between the client and server. In this way class marked [DataContract] will have methods (behavior) and [DataMember] fields/properties (state).

When you will pass such objects between client and server via WCF state will be persisted, but since class library is shared you will have methods on both sides.

Kirill Muzykov
I am such an idiot. I completely missed the obvious. I will test this to see if it works.
uriDium
If your client and service are both .Net then you can generate the client proxy using svcutil with the /r option to reference existing assemblies. Then the classes for you DataContracts can be shared.
Pratik
+2  A: 

DTOs that are decorated as DataContract classes are real objects. They can have methods in them, but the methods are not part of the serialization process.

The main time this will cause you issues is when:

  • you are relying on the generated proxy version of the DataContract objects (like when you have a Silverlight client calling a WCF service, or you are calling a third party service that you have no access to the code or its libraries). The generated proxy versions will not have the methods in them, just the DataMember properties. The way to get round that is to use objects from a shared library (as already mentioned by @Insomniac).

  • your properties in the DataContract objects are more than just a simple get/set operation, i.e. you may have included some logic to do other operations when a property value is set. In this case even the proxy generated version will not have that logic included. The ways to get round this is to either have the shared library, or have a partial class on the client side that extends the proxy generated class.

slugster
@slugser, the partial class solution I had also thought of. For the most part I will be able to provide the shared library. For other more secure stuff where I will use a webservice I will make sure to keep my objects simple.
uriDium
A: 

Sharing your classes between client and server projects is the way to go. Do not forget to check in your service reference that it tries to reuse types in referenced assemblies. That way, the service reference will not generate proxy classes for the shared objects.

Johann Blais
A: 

WCF at its core is a message-based system: your client proxy catches the call to a method, wraps up the method and all its parameters into a serialized message, and send that across the network to the service to be processed.

So yes - in the end, all that goes from client to server in WCF is a serialized message - typically in XML format. You cannot serialize behavior or methods with this approach.

marc_s