0
WPF에서는 복합 루트에서만 DI 컨테이너를 사용할 수없는 경우가 종종 있습니다. 루트에 모든 종속성을 설정했지만 단순히 루트에서 인스턴스화 할 수없는 뷰 모델을 인스턴스화해야 할 필요성을 느낍니다.WPF의 전역 DI 컨테이너
예를 들어 탭에 있거나 새로운 창에서 스폰되는 사용자 지정 컨트롤을 사용하십시오. 뷰 모델은 뷰 자체가 활성화 될 때 인스턴스화되어야합니다. 많은 뷰 모델에는 VM 생성자에 인터페이스로 삽입하는 대화 상자 공급자가 필요합니다.
DI 컨테이너를 서비스 위치 지정자로 사용하지 않습니다. 나는 생성자 주입에 대해 확고한 신봉자이지만, 내가 말했듯이 합성 컨테이너 루트를 훨씬 넘어서서 뷰 모델을 인스턴스화하기 위해 DI 컨테이너를 사용할 필요가있다. 지금까지 나는 내 애플 리케이션을 통해 사용할 수있는 DI 컨테이너를 호스팅하는 정적 클래스를 사용하고 있습니다.
여러분이이 문제를 어떻게 해결했는지 궁금합니다.
물론 사용할 수 있습니다. 객체를 제공하고 의존성으로 주입하는 팩토리를 생성 할 수 있습니다. 이는 공장에 대한 추가 코드를 의미하며 가독성을 줄이고 무엇을 얻게됩니까? DI 컨테이너에 대한 의존성이 느슨합니다. IMHO 노력은 이득에 관계가 없습니다. 또는 나는 무엇인가 놓치고 있냐? – Harald
'ServiceLocator'를 통해 쉽게 얻을 수있는 다소 어렵고 중복되는 느낌이 들지만,이 패턴을 [Anti Pattern]으로 간주하십시오 (http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti- 무늬/). 그럴 가치가 없다고 말할 수는 없지만 일단 그렇게하면 코드 기반을 실제로 느낄 것입니다. 이 주석을 읽으십시오, 여기에 [추상 공장 패턴]의 benifited 사람들이 있습니다 (http://stackoverflow.com/questions/1943576/is-there-a-pattern-for-initializing-objects-created-via-a-di). -container/1945023 # comment10021765_1945023). 따라서 IMO를 사용하면 실제로할만한 가치가 있습니다. 실제로 코드를 더욱 분명하고 깨끗하게 만듭니다. –