Проверьте, является ли привязка Ninject InRequestScope

Question

Если я получаю привязки для типа интерфейса из конкретного экземпляра ядра Ninject, есть ли способ проверить, какой тип привязки он (например: InSingletonScope(), InRequestScope())?

(упрощенный) пример:

IKernel kernel = NinjectWebCommon.CreateKernel(); 
var binding = kernel.GetBindings(typeof(IService)).FirstOrDefault(); 

var bindingType = binding...?? 

Answer 1

.InRequestScope() сам называет: IBindingSyntax.InScope(Func<IContext, object> scope);

В ScopeCallback (Func<IContext, object> scope) могут быть получены с помощью:

kernel 
    .GetBindings(typeof(IService)) 
    .Single() 
    .ScopeCallback 

Но сравнивая Func не очень хорошая вещь , Он чувствует себя очень хак, но мы можем сделать следующие действия для получения области действия запроса обратного вызова для сравнения:

private Func<IContext, object> RetrieveInRequestScopeCallback() 
{ 
    using (var kernel = new StandardKernel()) 
    { 
     kernel.Bind<object>().ToSelf().InRequestScope(); 
     return kernel.GetBindings(typeof(object)).Single().ScopeCallback; 
    } 
} 

теперь тестовый модуль как следующий будет проходить:

[Fact] 
public void Foo() 
{ 
    Func<IContext, object> inRequestScopeCallback = RetrieveInRequestScopeCallback(); 

    var kernel = new StandardKernel(); 
    kernel.Bind<string>().ToSelf().InRequestScope(); 

    IBinding binding = kernel.GetBindings(typeof(string)).Single(); 
    binding.ScopeCallback.Should().Be(inRequestScopeCallback); 
} 

(я использовал FluentAssertions и xunit)

Но, как я уже сказал, это хаки. Почему вы хотите проверить привязки? Я предлагаю, что было бы лучше инвестировать это время в создание автоматизированных интеграционных/системных тестов. Обычно это путь к контейнерам DI: вы не проверяете, правильно ли вы их настроили, вы проверяете это с помощью интеграционных и системных тестов.