내 IoC를 일반 설정 저장소로 사용하지 않을 이유가 있나요?

StackOverflow https://stackoverflow.com/questions/115039

  •  02-07-2019
  •  | 
  •  

문제

가정하자 애플리케이션 설정 클래스는 TimeoutPeriod, DefaultUnitOfMeasure, HistoryWindowSize 등과 같이 내 애플리케이션에 적용되는 설정의 일반 저장소입니다.그리고 MyClass가 이러한 설정 중 하나인 DefaultUnitOfMeasure를 사용한다고 가정해 보겠습니다.

Inversion of Control Containers의 적절한 사용에 대해 제가 읽은 내용은 – 제가 틀렸다면 정정해 주세요 – 생성자에서 클래스의 종속성을 정의한다는 것입니다.

public class MyClass {
  public MyClass(IDataSource ds, UnitOfMeasure default_uom) {...}
}

그런 다음 다음과 같이 클래스를 인스턴스화하도록 호출하십시오.

var mc = IoC.Container.Resolve<MyClass>();

어디 IData소스 구체적인 구현이 할당되었으며 default_uom이 연결되어 ApplicationSettings.DefaultUnitOfMeasure 재산.그러나 이 모든 고리가 실제로 점프하는 데 필요한 것인지 궁금합니다.내가 무슨 고민을 하고 있는 걸까?

public class MyClass {
  public MyClass(IDataSource ds) {
    UnitOfMeasure duom = IoC.Container.Resolve<UnitOfMeasure>("default_uom");
  }
}

예, 많은 수업이 다음에 의존하게 됩니다. IoC.컨테이너 하지만 그것은 내 수업의 대부분이 어쨌든 갖게 될 종속성입니다.클래스가 결합되어 있는 한 최대한 활용해야 할 것 같습니다.Agile 전문가님, 제가 어디가 잘못되었는지 알려주세요.

도움이 되었습니까?

해결책

IoC.Container.Resolve("default_uom");

나는 이것을 IoC 컨테이너를 서비스 위치 지정자로 사용하는 고전적인 안티 패턴으로 봅니다. 결과적으로 발생하는 주요 문제는 다음과 같습니다.

  • 컨테이너가 잘못 구성된 경우 애플리케이션이 더 이상 빠르게 실패하지 않습니다(특정 논리/상황 세트를 제외하고는 발생하지 않을 수 있는 코드에서 특정 서비스를 처음 해결하려고 시도할 때만 이에 대해 알 수 있습니다).
  • 테스트하기가 더 어렵습니다. 물론 불가능하지는 않지만 테스트를 위해 Windsor 컨테이너의 실제(반구성) 인스턴스를 생성하거나 IWindsorContainer의 모의로 싱글톤을 주입해야 합니다. 이로 인해 테스트에 많은 마찰이 추가됩니다. 생성자/속성을 통해 테스트 중인 클래스에 직접 모의/스텁 서비스를 전달할 수 있는 것과 비교됩니다.
  • 이러한 종류의 애플리케이션을 유지 관리하기가 더 어렵습니다(구성이 한 위치에 중앙 집중화되지 않음).
  • 기타 여러 소프트웨어 개발 원칙(DRY, SOC 등)을 위반합니다.

원래 설명에서 우려되는 부분은 대부분의 클래스가 IoC 싱글톤에 종속된다는 의미입니다. 클래스가 생성자/종속성을 통해 모든 서비스를 주입하는 경우 IoC와의 긴밀한 결합은 예외여야 합니다. 규칙 - 일반적으로 컨테이너에 의존하는 유일한 때는 까다로운 일을 할 때입니다.순환 종속성 문제를 피하려고 하거나 어떤 이유로 런타임에 구성 요소를 생성하려는 경우에도 일반 IServiceProvider 인터페이스 이외의 다른 것에 대한 종속성을 피하여 홈 베이크 IoC로 교체할 수 있는 경우가 많습니다. 또는 원래 프로젝트 외부 환경에서 구성 요소를 재사용해야 하는 경우 서비스 위치 지정 구현을 수행합니다.

다른 팁

일반적으로 IoC 컨테이너에 따라 클래스가 많지 않습니다.나는 일반적으로 다른 클래스에 주입하는 Facade 객체에 IoC 항목을 래핑하려고 시도하지만 일반적으로 대부분의 IoC 주입은 응용 프로그램의 상위 계층에서만 수행됩니다.

원하는 방식으로 작업을 수행하는 경우 테스트용 IoC 구성을 만들지 않고는 MyClass를 테스트할 수 없습니다.이렇게 하면 테스트를 유지 관리하기가 더 어려워집니다.

또 다른 문제는 IoC 구성 파일을 편집하여 구성을 변경하려는 소프트웨어 고급 사용자가 있다는 것입니다.이것은 내가 피하고 싶은 것입니다.IoC 구성을 일반 구성 파일과 IoC 관련 항목으로 나눌 수 있습니다.그러나 일반 .Net 구성 기능을 사용하여 구성을 읽을 수도 있습니다.

예, 많은 클래스가 IoC.Container에 대한 종속성을 가지게 되지만 어쨌든 이는 대부분의 클래스가 갖게 되는 종속성입니다.

나는 이것이 문제의 핵심이라고 생각한다.실제로 대부분의 클래스가 IoC 컨테이너 자체에 결합되어 있다면 디자인을 다시 생각해야 할 가능성이 있습니다.

일반적으로 앱은 부트스트래핑 중에 컨테이너 클래스를 한 번만 직접 참조해야 합니다.컨테이너에 대한 첫 번째 후크를 얻은 후에는 개체 그래프의 나머지 부분이 컨테이너에 의해 완전히 관리되어야 하며 해당 개체는 모두 IoC 컨테이너에 의해 생성되었다는 사실을 인식하지 않아야 합니다.

구체적인 예에 ​​대해 설명하려면 다음을 수행하십시오.

public class MyClass {
    public MyClass(IDataSource ds) {
        UnitOfMeasure duom = IoC.Container.Resolve<UnitOfMeasure>("default_uom");
    }
}

이렇게 하면 클래스를 재사용하기가 더 어려워집니다.더 구체적으로 말하면 제한된 사용 패턴을 벗어나 클래스를 인스턴스화하기가 더 어려워집니다.이것이 나타나는 가장 일반적인 장소 중 하나는 수업을 테스트할 때입니다.UnitOfMeasure를 생성자에 직접 전달할 수 있으면 해당 클래스를 테스트하는 것이 훨씬 쉽습니다.

또한 UOM 인스턴스 이름("default_uom")을 선택하면 클래스 사용법에 따라 값이 재정의될 수 있음을 의미합니다.이 경우 생성자의 값을 그런 식으로 "하드 코딩"하고 싶지 않을 것입니다.

생성자 주입 패턴 사용 하지 않습니다 클래스를 IoC에 종속시키십시오. 그 반대는 클라이언트에게 IoC 사용 여부에 대한 옵션을 제공하는 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top