IOC는 - 여러 의존성 사출

Question

는 아래의 고려 :

public class DependencyA {} 
public class DependencyB {} 
public class DependencyC {} 
public class DependencyD {} 

public class Service1 
{ 
    public Service1(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... } 
} 
public class Service2 
{ 
    public Service2(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... } 
} 
public class Service3 
{ 
    public Service3(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... } 
} 

내 서비스의 대부분은 여러 공통 구성 요소에 의존하는 것을 발견하고, 그리고 캐치에게 다음과 같은 모든 솔루션을 구현 생각하고 (모두 최대 유선 Windsor를 통해) 서비스 생성자에서 코드의 반복을 저장합니다.

public class DependencyContainer 
{ 
    public DependencyA A { get; set; } 
    public DependencyB B { get; set; } 
    public DependencyC C { get; set; } 
    public DependencyD D { get; set; } 
} 

public class Service1 
{ 
    public Service1 (DependencyContainer container) { ... } 
} 

또는 ServiceBase 클래스를 만들 수 있습니다.

실제 질문은 서비스에서 더 넓은 디자인 문제를 강조합니까?

아마도 저는 DI를 너무 멀리하고 있습니다. 그러나 이것들은 모두 진정한 의존성입니다.

그렇다면 어떻게 코딩해야합니까? 제안 된 솔루션이 목표를 달성하는 유효한 방법이 아닌 경우?

Answer 1

을 할 수 없다. 다른 말로 표현하자면 그것은 아마 단일 책임 원칙을 위반하는 것입니다.

Answer 2

더 광범위한 컨텍스트가 없으면이 문제에 관해 이야기하기가 어렵지만 너무 정교한 종속성을 처리 할 수 ​​있습니다. 4 가지 종속성이 함께 속해 있습니까? 그들은 하나의 응집 된 전체로서 의미가 있습니까?

그렇다면 접근 방법이 매우 유용합니다.

그렇지 않은 경우 건축물의 벽에 부딪 힐 수 있습니다. 하나 이상의 (내재적으로 존재하는) 엔티티에 넣어야하는 책임이 다른 엔티티에 첨부되는 방식으로 도메인을 분할했을 수 있습니다. 이 경우 도메인을 살펴보고 반복적 인 암시 적 엔터티를 식별하여 명시 적으로 지정하고 동작을 해당 엔터티로 이동시켜야합니다. 그러나 이것은 훨씬 더 어려운 문제이며 도메인 및 응용 프로그램에 매우 중요합니다.

그리고 서비스가 너무 많은 일을하는 것을 표시 할 수 있습니다 당신의 서비스에 너무 많은 의존성을 갖는 IOC의

와