Создавать пользовательские типы возвращаемых данных при переносе веб-службы в адаптер?

Question

В настоящее время я работаю с API веб-служб Exchange (EWS) и нахожусь в процессе создания адаптера для общих задач, таких как синхронизация электронной почты, а также получение электронной почты на основе идентификаторов.Я знаю, как создать адаптер, но я немного не уверен, как обрабатывать возвращаемые типы.

Например, при выборке элементов по идентификатору с помощью EWS я использую BindToItems(IEnumerable<ItemId> itemIds, Microsoft.Exchange.WebServices.Data.PropertySet propertySet), который имеет тип возвращаемого значенияиз IEnumerable<GetItemResponse>.

Итак, мой вопрос заключается в том, могу ли я создать IExchangeServiceAdapter и имитировать сигнатуры функций, которые я хочу, или я создаю собственные типы возврата для всего?Это означает, что я хотел бы добавить что-то вроде public IEnumerable<CustomResponseType> BindToItems(IEnumerable<CustomItemIdType> itemIds, PropertySet propertySet).

. Это все для того, чтобы я смог протестировать мой сервис и выполнить его макет.

Редактировать

Возможно, лучший вопрос, при создании сервисных адаптеров (или оболочек или фасадов) я должен создать адаптер для всего, включая возвращаемые типы и параметры для только что мне нужно?Так, скажем, когда привязка элементов, как показано выше, и я добавляю в CustomResponseType только некоторые из многих свойств, которые мне требуются.Это, в свою очередь, потребовало бы от меня создания сопоставления между реальной реализацией (например, GetItemResponse) и моей адаптированной реализацией CustomResponseType.

. Есть ли какие-нибудь хорошие примеры C #, которые делают то, чего я пытаюсь достичь?

Answer 1

Я не очень знаком с API веб-службы Exchange, но в подобных ситуациях я предпочитаю использовать пользовательские типы возвращаемых данных и использовать Automapper для передачи данных между двумя типами объектов.

Я думаю, что это дает некоторые преимущества:

1. Вы передаете только те данные, которые вам нужны. Дополнительная информация, которая не нужна, исключается из уравнения.
2. Уменьшена поверхность атаки. Поскольку нет ненужных полей, которые нужно игнорировать, вы не будете открыты для чрезмерной публикации уязвимостей.
3. Снижение сетевого трафика. Очевидно.
4. Объединение объектов данных. Могут быть случаи, когда вы хотите вернуть больше данных, чем обеспечивает встроенный объект. Это может превратить один вызов в два, или вы все равно должны сделать пользовательский объект.
5. Биржа черного бокса. Вы не будете раскрывать некоторые внутренние принципы работы EWS. Это позволяет вам упростить или, возможно, расширить сферу действия вашего собственного сервиса.

Самый большой недостаток, который я могу вспомнить, - это управление версиями интерфейса. Если вы хотите добавить свойства, вам придется изменить свой контракт с данными. Но это может произойти с номером 4 выше.

В конце концов, вам нужно решить, какой способ лучше всего подходит для вашей ситуации. И как лучше всего решить деловую проблему под рукой.