DI / IoC 컨테이너와 팩토리 : 어플리케이션을 어디서 구성하고 왜합니까?


9

소프트웨어를 구성하기 위해 DIC / IoC 레지스트리를 사용하는시기와 팩토리를 사용하는시기 및 두 가지 접근 방식의 추론을 파악하려고합니다.


구조 맵을 DI 컨테이너 (DIC)로 사용하고 있는데, 이는 레지스트리를 사용하여 쉽게 구성 할 수 있습니다. DIC에서 실제로 등록 된 모든 객체는 정적이므로 의미가 있습니다 .DIC가 구성되고 DIC에서 싱글 톤으로 구성되면 런타임에 구현 / 인스턴스를 변경 / 교환 할 필요가 없습니다. 그러나 소프트웨어 (SW)가 다른 장치 에서 실행되므로 하드웨어를 적절하게 구성하려면 SW가 실행되는 장치에 따라 장치 별 레지스트리를 선택 해야 합니다.

일부 객체를 구성하려면 구성 파일을 읽어야하므로 팩토리를 사용하여 이러한 인스턴스를 DIC에 반환하여 구성 읽기와 객체 작성을 분리합니다. 해당 플러그인 유형에 대해 팩토리 getter를 DIC에 등록했습니다.

지금은 플러그인 유형이 있다고 IMotor콘크리트 종류 Motor1Motor2공장에 의해 처리되어야한다. 이제 장치 구성 방법을 결정할 수있는 두 가지 방법이 있습니다.

  1. 나는 SW가에 실행되고있는 장치에 대한 정보를 전달 MotorFactory하고 올바른 모터를 반환하거나 Motor1또는 Motor2. 이 경우 결정 논리 는 공장 내부 에 있습니다.
  2. 나는 그것을 실행하고 두 개의 공장을 생성하는 장치에 따라 DIC를 구성 Motor1Factory하고 Motor2Factory하나가 생성하는 경우, Motor1다른 Motor2. 이 경우 또는 IMotor중 하나를 사용하는 장치 별 레지스트리에 다른 레지스트리 항목 이 있습니다 .Motor1FactoryMotor2Factory

이제 내 질문은 :이 두 가지 방법 중 어느 것이 선호되고 왜? 필자는 코드베이스 전체에서 인스턴스화 할 유형을 결정하는 논리를 퍼 뜨리고 있기 때문에 첫 번째 경우는 간단하고 복잡하지 않은 것 같습니다. 두 번째 경우에는 코드의 팩토리 수를 효과적으로 곱하는 것입니다. 각 콘크리트 유형마다 (거의) 팩토리가 필요하기 때문입니다. 추상 팩토리가 믹스에 추가되면 더 혼란 스럽습니다.

다시 한 번 : 한 가지 방법을 사용해야합니까? 그리고 더 중요한 것은 : 어떤 길을 갈지를 결정하는 좋은 지표는 무엇입니까?


2
어느 방법이 더 간단합니까? 보다 복잡한 접근 방식의 이점이 추가 복잡성 비용을 능가합니까?
Robert Harvey

답변:


2

둘 다 사용하면 간단한 것으로 갈 것입니다.

  • DI / IoC : 런타임에 변경되지 않는 모든 구성.
  • Factory : 런타임 입력 매개 변수에 따라 런타임에 개체 인스턴스를 만드는 데 사용됩니다. 공장의 인스턴스는 DI 컨테이너에 의해 주입됩니다.

1

추상 팩토리는 서로 달라야하는 계층 구조를 통해 관련된 개체가있을 때 사용됩니다. 나는 여기에 보이지 않습니다.

내가 보는 것은 공장에서 모터를 선택해야하는지 또는 DIC가 특정 모터를 생산하는 공장을 선택해야하는지 궁금하다는 것입니다.

공장과 DIC는 매우 유사한 일을하기 때문에 정확하게 선택하기는 어렵습니다. 차이점은 공장이 특정 문제에 초점을 맞추고 DIC가 더 일반적이라는 것입니다.

이 질문에 귀착됩니다 : 공장에서 살 수있는이 문제와 관련된 코드가 필요합니까? 아니면 파일에서 구성 세부 정보를 읽는 것이 더 일반적입니까?

오늘 Motor1Motor2오늘 사이에서만 선택할 수 있지만 내일은있을 수 있습니다 Motor3. Motor3쉽게 추가 할 수있는 디자인을 선호 하십시오.


0

"사용할 모터"라는 로직을 Builder (패턴) 라는 특수 팩토리 로 분리하고 빌더의 구현 세부 사항으로 두 모터 모두에 IOC- 컨테이너를 사용합니다.

일반적으로 :

  • 클래스 / 인터페이스의 동적 객체를 많이 만들어야하는 경우 팩토리 (또는 빌더)가 필요합니다. (즉, 생산하는 모든 자동차에 대해 하나의 새 모터를 만들어야합니다)
  • 클래스의 정적 인스턴스가 하나만 필요한 경우 ioc / di가 작업을 수행 할 수 있습니다 (즉, 지불 서비스의 정적 인스턴스 하나와 MotorBuilderService의 정적 인스턴스 하나만 필요).
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.