Создать зависимости службы WCF на основе дополнительных параметров - PullRequest
1 голос
/ 14 января 2011

В нашем проекте ASP.NET у нас есть интерфейс службы диспетчера сеансов, который мы используем, чтобы узнать информацию о текущем пользователе. Например:

var actorId = _sessionManager.CurrentActivePerson.PersonId;

Этот диспетчер сеансов предоставляется классам посредством внедрения зависимостей на основе конструктора.

Теперь у нас есть служба WCF, которую мы хотели бы создать с различными привязками DI в зависимости от ситуации:

  • Если потребитель предоставил имя пользователя для сеанса, мы хотели бы использовать менеджер сеансов, который считает этого пользователя текущим человеком.
  • В противном случае мы хотим как-то потребовать предоставления идентификатора домена, использовать менеджер сеансов, который привязан к системному сотруднику для этого домена.

Чтобы это работало правильно, нам нужно разрешить потребителю указывать идентификатор домена в качестве аргумента, хотя он не указан в качестве аргумента самой службы. Затем нам нужно иметь доступ к этому аргументу из метода привязки DI, пока HostFactory создает экземпляр службы.

У кого-нибудь есть предложения по поводу того, как мы можем это сделать?

Примечания:

  • Я уже знаю, как вообще создавать зависимые привязки: вопрос в том, чтобы передать этот дополнительный параметр фабрике сервиса.
  • Служба WCF предоставляется в качестве конечной точки SOAP и использует защиту на основе сертификатов.

1 Ответ

2 голосов
/ 15 января 2011

Мне кажется, это аутентификация / авторизация проблема больше, чем проблема DI. В таком случае наиболее правильным решением на низком уровне будет реализовать собственный токен .

Это довольно сложная задача, поэтому вам следует серьезно подумать о переходе на авторизацию на основе утверждений . Windows Identity Foundation предоставляет множество инструментов для этого.

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

Однако, если вам действительно нужно отложить разрешение зависимости до фактического вызова метода, универсальным решением является внедрение абстрактной фабрики .

На всякий случай, если вам нужна информация о том, как включить Конструктор Injection для WCF, вот как: Инъекция данных в службу WCF

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...