Как вы отделяете веб-сервис, который требует authheader при каждом вызове? - PullRequest
Новая
       0

Как вы отделяете веб-сервис, который требует authheader при каждом вызове?

2 голосов
/ 27 сентября 2011

У меня есть сервисная ссылка на веб-сервис .NET 2.0. У меня есть ссылка на этот сервис в моем хранилище, и я хочу перейти на Ninject. Я использую DI уже некоторое время, но не пробовал его с таким веб-сервисом.

Итак, в моем коде конструктор хранилища создает два объекта: клиентский прокси для службы и объект AuthHeader, который является первым параметром каждого метода в прокси.

AuthHeader - это место, где у меня трения. Поскольку конкретный тип требуется в качестве первого параметра при каждом вызове прокси-сервера, я считаю, что мне нужно взять зависимость от AuthHeader в моем репозитории. Это правда?

Я извлек интерфейс для AuthHeader из моего reference.cs. Я хотел перейти к следующему для моего конструктора хранилища: 

[Inject]
public PackageRepository(IWebService service, IAuthHeader authHeader)
{
    _service = service;
    _authHeader = authHeader;
}

... но тогда я не могу звонить своему прокси-серверу, например 

_service.MakeSomeCall(_authheader, "some value").

... потому что MakeSomeCall ожидает AuthHeader, а не IAuthHeader.

Я что, воткнул квадратную круглую дыру? Является ли это просто областью, в которой нет естественного соответствия (из-за «удивительности» веб-службы)? Я пропускаю подход?

1 Ответ

1 голос
/ 23 октября 2011

Трудно точно понять, в чем тут вопрос, но некоторые общие рекомендации могут иметь отношение к этой ситуации:

  1. Внедрение зависимостей не означает, что все должно быть интерфейсом.Я не уверен, почему вы пытаетесь извлечь интерфейс из прокси-сервера веб-службы, сгенерированного из WSDL;типы в WSDL - это контракты, которым вы должны следовать.Это особенно глупо, если IAuthHeader не имеет никакого поведения (кажется, что нет), и у вас никогда не будет альтернативных реализаций.

  2. Причина, по которой все выглядит такнеправильно, потому что это это неправильно;этот веб-сервис плохо спроектирован.Информация, которая является общей для всех сообщений (например, токен аутентификации), никогда не должна помещаться в body , где она преобразуется в параметр метода;вместо этого он должен идти в сообщении header , где иронически названное AuthHeader явно не .Заголовки могут быть перехвачены прокси-сервером и проверены перед выполнением любой операции на стороне клиента или службы.В WCF это часть поведения (обычно ClientCredentials для аутентификации), а в устаревшем WSE это делается как расширение.Хотя теоретически это возможно сделать с помощью информации в теле сообщения, гораздо сложнее сделать это надежно.

  3. В любом случае, что действительно важно, здесь не так уж много От чего зависит ваше хранилище, но , откуда , откуда берется эта зависимость.Если ваш AuthHeader внедрен ядром как зависимость, вы все равно получаете все преимущества DI - в частности, возможность зарегистрировать все это в одном месте или заменить другую реализацию (т.е. производный класс).

Так что, если оставить в стороне вопросы дизайна, я не думаю, что у вас есть реальная проблема в реализации DI.Если классу нужно взять AuthHeader, введите AuthHeader.Не беспокойтесь о точном синтаксисе и типе, поскольку эта зависимость принимает аргумент или свойство конструктора.

...