Ninject Providers : 종속성을 해결하는 올바른 방법은 무엇입니까

Question

내 응용 프로그램에서 다른 데이터 소스를 이름으로 등록 할 수 있습니다. 이 데이터 소스에는 각각 약간의 string 속성이 필요하며 다른 종속성 세트도 있지만 그 외의 경우에는 동일하므로 몇 가지 다른 표준 구현을 사용하십시오.

요청시 각 데이터 소스의 인스턴스를 생성하려면 해당 데이터 소스에 액세스하는 데 필요한 정보로 초기화되는 Provider<T>의 인스턴스에 대한 바인딩을 만듭니다.

public class StandardListProvider<T> : Provider<IListExecutor<T>> 
    where T : new() 
{ 
    public string Name  { get; set; } 
    public string ListMethod { get; set; } 

    public StandardListProvider(string name, string listMethod) 
    { 
     Name  = name; 
     ListMethod = listMethod; 
    } 

    protected override IListExecutor<T> CreateInstance(IContext context) 
    { 
     var connector = (IInternalConnector)context.Kernel.GetService(typeof(IInternalConnector)); 
     return new StandardListExecutor<T>(connector, Name) 
     { 
      ListMethodName = ListMethod 
     }; 
    } 
} 

문제는 IInternalConnector 같은 StandardListExecutor<T>의 의존성을 해결 함께 : 공급자는 다음과 같이 보입니다. 분명히 수동으로 생성 할 수도 있고 context.Kernel에서 요청할 수도 있습니다 (예 : Ninject Providers -> Get another dependency inside the provider). 대상 정보가없는 요청이 발생합니다. 종속성에 대한 컨텍스트 바인딩을 수행하려는 경우에는 이상적이지 않습니다. StandardListExecutor입니다.

context.Request.CreateChild(...)으로 시도해 보았지만 활성화 할 때마다 ParameterTarget을 생성해야합니다. 이것에 관한 많은 정보가 Ninject 문서에도 나타나지 않습니다.

내 질문은 : 기존 바인딩의 활성화 프로세스 내에서 의존성 또는 이와 같은 기타 서비스를 해결하는 정확한 방법은 무엇입니까?

편집

자체가 System.Web.Mvc 컨트롤러 활성화 과정에 Ninject.Mvc의 만남을 통해 만들어진 요청이.

Answer 1

Ninject.Extensions.ContextPreservation 확장자를 사용할 수 있어야합니다. 특히 확장 방법 IContext.ContextPreservingGet(...)은 : - 그것은 단순한 생각 때문에

var connector = context.ContextPreservingGet<IInternalConnector>(); 

그러나, 개인적으로는 특정 설정 유형을 만드는 것이 더 나은 선택이라고 생각합니다.