views:

129

answers:

1

I am currently looking to design some WCF services and wanted to get the community's opinion on the best way to handle operation / data contracts.

I have 2 basic operation contracts, the first creates a quote and the second adds an item to a quote (and calculates totals behind the scene).

The first takes in customer information and store information and returns a quote.

The second takes in a quote and an item object, calculates totals and returns a quote with the item.

My question is about how to design the data contracts in this scenario?

For the CreateQuote, should a quote object be passed in with a customer property and a store property set or should there be some kind of QuoteRequest object which contains a customer & store object but with no quote object passed in?

For the AddQuoteItem, should a QuoteItem object be passed in with required properties set including a Quote object or should there be a QuoteItemRequest object that has a Quote object and an item object (with no relation) and then a recalculated Quote with a QuoteItem object is returned?

In other words should they look something like this?

Quote CreateQuote(Quote quote);

Quote AddQuoteItem(QuoteItem quoteItem);

Or should they look something like this?

Quote CreateQuote(QuoteRequest quoteRequest);

Quote AddQuoteItem(QuoteItemRequest quoteItemRequest);
+2  A: 

I would argue that wrapping them in request/response wrappers might prove to be a little superfluous. You can always presume that parameters to WCF service methods are the "request" and the return type is the "response".

In your scenario, pass a Customer type and Store type to the CreateQuote method and return a Quote type. Then pass a Quote type and return either your Quote type again, or a bool indicating success instead, to the AddQuoteItem method.

Again in your scenario, your request/response classes would simply be one-level wrappers around a single type. I could only envisage a scenario where you would return a response-esque class to wrap multiple different types in the method's single return value.

Adam
Thanks Adam - To clarify why I might want a QuoteRequest data contract - to hold 2 objects namely a customer and a store object (so it wouldn't be a "one-level wrappers around a single type" as you mentioned.
KenB
True, but you can have multiple parameters in a method signature, so it's not necessary for that.
Adam
I don't think that is the best solution. According to best practice articles service contracts should only have one parameter which wrap parameters.Check out this article for more info: http://goo.gl/Qo9J
KenB
Good point; and there is your answer. If your service is likely to receive requests from MSMQ, then you will at some point need to wrap the parameters in messages. However, if it isn't going to, then you may end up over-complicating the public API of the service where you don't necessarily need to.
Adam
Don't forget, the solution only needs to meet your current business requirements leaving a sensible level of room for improvement/change. Anything that doesn't fall into sensible shouldn't be catered for up-front.
Adam