Ninject WCF: инъекция атрибутов

Question

Я использую проект расширения Ninject WCF для внедрения зависимостей в мой веб-сервис.Если я добавлю атрибут в свой веб-сервис (например, IServiceBehavior), как я могу внедрить зависимости в этот атрибут при его создании во время выполнения?

Answer 1

Атрибуты создаются .NET Runtime. Поэтому для них не существует реального внедрения зависимостей. Вы должны по возможности избегать наличия атрибутов, которые требуют зависимостей. У вас есть следующие варианты:

1. Поведение службы может быть добавлено без атрибутов. Но для этого необходимо, чтобы вы расширили текущее расширение WCF некоторым способом, чтобы определить, что вы хотите добавить поведение службы для некоторых экземпляров аналогично тому, как это в настоящее время возможно для фильтров MVC. Это сделано здесь: https://github.com/ninject/ninject.extensions.wcf/blob/master/src/Ninject.Extensions.Wcf/ServiceHost/NinjectServiceHost.cs
2. Вы можете реализовать провайдера IInstance, который ищет ваши атрибуты и внедряет их. Смотри https://github.com/ninject/ninject.extensions.wcf/blob/master/src/Ninject.Extensions.Wcf/NinjectInstanceProvider.cs

Я бы попробовал выбрать первый вариант.

Answer 2

Я не согласен с тем, что атрибуты не должны иметь зависимостей в них. Часто атрибуты проверки будут иметь неизбежные зависимости. Атрибуты являются отличным примером СУХОГО при правильном использовании.

Подход @wllmsaccnt, по сути, является подходом KernelContainer, который был удален в 2.2 - но хуже. Теперь атрибут связан с приложением WCF.

IMO, именно поэтому я не согласен с удалением KernelContainer. Я определенно предпочел бы внедрение по сравнению с сервисным локатором, но я действительно не понимаю, почему сервисный локатор не рекомендуется, когда вы работаете в системах, которые вы не можете изменить или контролировать.

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