You're at the service's end of the wire and you don't know your clients.
Why would you choose one over the other?
You're at the service's end of the wire and you don't know your clients.
Why would you choose one over the other?
As a rule of thumb; when designing a type yourself it should be a class, unless the type represents a single value, in which case it should be a struct.
Fredrik has the correct answer. I'll only add that you should keep in mind that the client will never see your Data Contract. It will be translated into XML Schema and will be included in the WSDL. On the client side, recall, it could be a Perl or even Classic ASP client - something that has no concept of value vs. reference semantics.
So value vs. reference is something that only matters to the service - not to the clients.
Well in the class vs struct war, if you're gonna use the structs in a collection, you're never going to be able to change their values, when you foreach through the collection.
So you lose alot of functionality, moral of the story, use classes
Actually, John Saunders isn't totally correct. The WSDL generated by WCF does infact indicate whether or not the objects are value or reference types. When you have WCF on the client side, you can take advantage of this. Also, value vs reference has an impact on the isNullable attribute of various parts of the WSDL which can change the semantics.
Of course, you need to make sure that you don't paint yourself into an incompatibility corner - a nullable value type is not necessarily the same thing as a reference type (or even possible) in some client environments.