Search code examples
c#wcfsoapdatacontractoperationcontract

Designing WCF Contracts (Operation / Data)

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);
Solution

  • 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.