WCF DataContract Design Help - Few common classes vs. Specific classes

[chirag....@gmail.com]

Hi,

I'm designing a WCF service right now.

I do not have any kind of validation in the wcf service layer. WCF
service is being developed on top of another tcp service, which will
handle all the validation and business processing.

I have created datacontract classes as if I would do my DataEntity
classes. Mean if I had to represent a "product", I would create a
Product entity class with all the properties representing product
information.

This single class will be used as input parameter to many service
methods and also will be used as return parameter.

My question is about taking another approach, Should I do that? Is
that a better design to go with the following design rather than
previous one.

I will not define a single Product entity class. Rather I will define
separate classes for every different set of input parameters(request)
and every different set of responses/return types. (Also even if only
single value is needed for input/output, I will wrapp it into a class)

Consequences.
- I will not be able to reuse any properties (in my case, even
inheritance won't help). Rather I will have repeatation of same
properties in many classes.
- I will land up with many number of datacontracts, but it will help
end clients in a way that they willl always know what they have to
input and what they will get in output because there are no extra
properties in the Object that they will pass or get.

Well, another possibility is that I keep using the first design. But
provide service methods to construct objects of input, so that end
users don't have to select which properties need to be set and which
are just extra.

Thanks!