NInject 및 MVC 3 - [Inject] 속성 대신 DependencyResolver를 사용해야합니까?

Question

최근 MVC 3과 Ninject 2로 옮겼습니다. 대부분의 코드에서 생성자 삽입을 사용하지만, Inject 속성을 사용해야하는 곳이 있습니다. Ninject 2는 자신의 IDepencyResolver 인터페이스를 등록합니다. 가있을 때 그 기능은 이제 MVC 정말 엄격하게 관련 아니지만, 때문에 나는

public SomeClass 
{ 
    public IUserService UserService { get; set; } 

    public SomeClass() 
    { 
     UserService = DependencyResolver.Current.GetService<IUserService>(); 

대신

public SomeClass 
{ 
    [Inject] 
    public IUserService UserService { get; set; } 

할 수있는, System.Web.Mvc 네임 스페이스의 일부가되는 DependencyResolver 클래스를 좋아하지 않는다

그래서 내 클래스에 Ninject 네임 스페이스를 참조 할 필요가 없습니다. DependencyResolver을 그렇게 사용해야합니까?

Answer 1

클래스의 올바른 작동에 필요하지 않은 종속성에 대해서만 속성 주입을 사용하지만 사용자가 설정 한 경우 일부 기능을 추가 할 수 있습니다. 이러한 기능의 예는 로깅입니다. 따라서 사용자가 자신의 구현을 제공 할 수있는 로거를 나타내는 속성을 가질 수 있으며 클래스가 정상적으로 작동하지만 계속 로그하지 않으면 간단히 수행 할 수 있습니다.

다른 모든 경우에는 생성자 주입을 사용합니다. 이렇게하면 소비자에게이 클래스가 다른 서비스에 대한 의존성이 있음을 나타냅니다.

public SomeClass 
{ 
    public IUserService UserService { get; set; } 

    public void SomeMethodWhichDoesntEnforceUserService() 
    { 
     if (UserService != null) 
     { 
      // Provide some additional functionality 
     } 
    } 
} 

및 클래스는 사용자의 서비스없이 제대로 작동 할 수없는 경우 : 두 경우에 따라서

public SomeClass 
{ 
    private readonly IUserService _userService; 
    public SomeClass(IUserService userService) 
    { 
     _userService = userService; 
    } 

    public void SomeMethodWhichRequiresTheService() 
    { 
     _userService.DoSomething(); 
    } 
} 

없이 참조

그래서 단순히이 나는 것 속성 주입에 대한 귀하의 질문에 대답하기 DI 세부 사항까지 이것이 Inversion of Control이 의미하는 것입니다.

Answer 2

SomeClass에 IUserService의 생성자 주입을 수행 할 수없는 이유는 무엇입니까? 디자인에 문제가 있음을 나타낼 수 있습니다.

DependencyResolver을 직접 참조하지 않으려면 DI 프레임 워크에서 서비스 로케이터의 추상화를 구현할 수 있습니다. CommonServiceLocator이지만, this question에 대한 답은 DI를 올바르게 수행 할 때 그러한 추상화가 필요하지 않아야 함을 나타냅니다. 대신 응용 프로그램의 디자인을 조정해야합니다.

Answer 3

mvc3 용 ninject.web.mvc 버전이 필터 속성에 생성자 삽입을 지원한다고 생각합니다. 너 해봤 어?