давайте думать о интерфейсе, как это:Использование Ninject для автоматического создания классов
public interface ITest
{
void DoSomething();
}
Я не хочу, чтобы реализовать этот интерфейс, и попросить Ninject сгенерировать прокси-класс, реализующий его. Затем метод Intercept DoSomething. Является ли это возможным?
Насколько я знаю, из коробки ninject не поддерживает прокси-серверы перехвата без реализации (наследуемый от интерфейса класс i.E.). Если вы хотите прокси-интерфейс интерфейса с реализацией только перехватчиками, ни один класс, то вы можете использовать «прокси-сервер без интерфейса» gate.dynamicproxy (см. http://docs.castleproject.org/Tools.Kinds-of-proxy-objects.ashx), но вам придется реализовать саму привязку самостоятельно.
В качестве альтернативы вы можете попробовать использовать https://github.com/ninject/ninject.extensions.interception и .Bind(). ToConstant (Mock.Of) .Intercept(). With (new SomeInterceptor) ;.
Благодаря BatteryBackupUser, я нашел решение таким образом:
kernel.Bind (typeof (ITest)). To (typeof (Class1)). Перехват(). С ((IInterceptor) новый MyInterceptor());
Class1 - пустой класс, а MyInterceptor должен реализовывать интерфейс IInterceptor. – themehrdad
Почему бы вам не реализовать этот интерфейс. Что-то вонючее об этом. Можете ли вы объяснить, каков ваш реальный сценарий? Почему бы вам не реализовать этот интерфейс? – Steven
@Steven: Вот полный сценарий: Подготовка каркаса для клиента. Я хочу, чтобы они определяли свои интерфейсы для своих сервисов, таких как: IEmployeeService, который имеет такой метод, как GetAllEmployees. Затем они должны реализовать эту службу для серверной стороны с помощью WCF. но моя инфраструктура автоматически реализует интерфейс для создания прокси-класса на стороне клиента с использованием ninject и обработки исключений, ведения журнала, ... Поэтому реальный случай заключается в том, что я не знаю об их интерфейсах, которые они собираются определить в будущем , :) – themehrdad