Question

I’m currently working with the Exchange Web Services (EWS) API and am in the process of creating an adapter for common tasks such as syncing emails as well as fetching emails based on ids. I’m aware of how to create the adapter, however I’m a little unsure as how to handle return types.

For example, fetching items by id with EWS I use BindToItems(IEnumerable<ItemId> itemIds, Microsoft.Exchange.WebServices.Data.PropertySet propertySet) which has a return type of IEnumerable<GetItemResponse>.

So my question is do I create IExchangeServiceAdapter and mimic the function signatures that I want or do I create custom return types for everything? Meaning I would add something like public IEnumerable<CustomResponseType> BindToItems(IEnumerable<CustomItemIdType> itemIds, PropertySet propertySet).

This is all for enabling me to unit test my service and mock it out.

Edit

Perhaps a better question is, when creating service adapters (or wrappers or facades) do I create an adapter for everything including return types and parameters to only what I need? So say when binding items like is shown above and I only add in my CustomResponseType the few out of many properties that I require. This in turn would require me to create mapping between the real implementation (e.g. GetItemResponse) to my adapted implementation of CustomResponseType.

Are there any good C# samples that do what I’m trying to achieve?

Answer 1

I’m not that familiar with the Exchange Web Service API, but my preference in similar situations is to use custom return types, and use Automapper to transfer the data between the two object types.

I think this provides some benefits:

1. You only pass around the data that you need. Extra information that is unnecessary is left out of the equation.
2. Reduced attack surface. Since there are no unnecessary fields to be ignored, you won’t be open to over-posting vulnerabilities.
3. Reduced network traffic. Obviously.
4. Combining data objects. There may be times when you want to return more data than what the built-in object provides. That can turn one call into two, or you have to make a custom object anyway.
5. Black boxing Exchange. You won’t be exposing some of the inner workings of the EWS. This allows you to simplify or perhaps broaden the reach of your own service.

The biggest drawback I can think of is versioning the interface. If you want to add properties, you’ll have to change your data contract. But that can happen with #4 above anyway.

In the end, you’ll have to decide which way works best for your situation. And how to best solve the business problem at hand.