IoC 컨테이너에서 자체 바인딩이란 무엇입니까?

Question

아래 코드에서와 같이 의존성 주입 프레임 워크를 사용할 때 Ninject와 같은 프레임 워크와 Stack의 게시물이 자기 바인딩에 대해 이야기하는 것을 보았습니다.

Bind<Samurai>().To<Samurai>(); 

그들은 심지어이 특별한 구문을 갖는 범위로 이동 :

Bind<Samurai>().ToSelf(); 

이 왜 자체에 유형을 결합 할 것인가? 이 방법이 유용 할 수있는 곳에서 실제 응용 프로그램을 보지 못하고 코드의 종속성을 줄이는 데 도움이됩니다. 이것은 단순히 유형에 대한 참조가 단순히 자체적으로 해결된다는 것을 의미하지 않을까요?

Answer 1

종속성 주입을 적용하고 Dependency Inversion Principle을 준수 할 때 일반적인 조언은 to program to interfaces, not implementations입니다. 대부분의 시간은 당신이 구현에 추상화에서 이동 바인딩 볼 이유 :이 구성 요소가 컴파일시에 IWarrior에 대한 종속성을 가지고 것을 의미합니다

Bind<IWarrior>().To<Samurai>(); 

을, 우리는 런타임에 Samurai을 주입.

그러나 특정 조건 하에서는 구체적인 구성 요소에서 자체로 매핑하는 것이 좋습니다. 즉, '누군가'가 Samurai을 요청하는 경우이를 Samurai과 함께 제공합니다.

가장 중요한 경우는 루트 유형을 확인할 때입니다. 루트 유형은 종속성 그래프의 맨 위에 있습니다. 루트 유형은 컨테이너에서 직접 확인됩니다. 다른 모든 유형은 루트 유형의 직접 또는 간접 종속성입니다.

종종 이러한 루트 유형은 구체적인 유형으로 해결되며 종종 우리는 UI 프레임 워크를 다루고 있습니다. 웹 폼 Pages, MVC Controllers, 웹 API ApiControllers 등이 있습니다.

대부분의 DI 컨테이너를 사용하면 구체적인 등록되지 않은 유형을 확인할 수 있습니다. 이것은 자기 구속력이 중복된다는 것을 믿게 할 수도 있지만 항상 그런 것은 아닙니다. 이러한 바인딩을 명시 적으로 추가하면 컨테이너가 그러한 바인딩의 존재를 알 수 있습니다. 이것은 컨테이너의 진단 기능 (있는 경우)을 사용하여 객체 그래프에서 오류를 검사하는 이점이 있습니다. 이러한 기능이없는 경우 일반적으로 알려진 등록을 반복하고 단위 테스트 내에서 일부 확인을 수행 할 수 있습니다. 컨테이너의 등록이 반복 될 때 의미있는 검증이 이루어지기 위해서는 모든 루트 유형을 컨테이너에 등록해야합니다. 그렇지 않으면이 확인 과정에서 가음새가 발생합니다.

DI 컨테이너에 자동 바인딩을 알리는 또 다른 이유는 컨테이너가 등록되지 않은 유형을 확인할 수 없거나 컨테이너의 기본 라이프 스타일과 다른 라이프 스타일로 등록해야하는 경우입니다. 유형이 등록되지 않은 경우 대부분의 컨테이너는 Transient 인스턴스를 제공합니다.