CodecampServer의 정적 팩토리 가 잘 알려진 패턴입니까?

Question

CodeCampServer 소스 코드에는 일반적인 것이 포함되어 있습니다 정적.

나는 이것이 프레임 워크가 종속성 주입과 어떻게 잘 작동하는지에 대한 메커니즘의 핵심 조각이라고 추측하고있다.

의존성 해상도 메커니즘이 작업 항목으로 대체 할 수있는 기본 구성되지 않은 상태에 정적 액세스를 제공하기 위해 기본적으로 사용하는 서브 클래스가 사용됩니다.

나는 이것에 대한 문서를 찾을 수 없었습니다 ...

좋은 설명이 있습니까? 그 책? (아마존에서 배달을 기다리고 있습니다 ...)

... 아니면 다른 사람이 이것이 무엇인지, 그리고 내가이 패턴을 채택하는 것이 현명한 지에 대한 좋은 논평을 제공 할 수 있습니까?

업데이트

Jeffrey Palermo 가이 질문에 대답했기 때문에 MVC2에 대한 (진행중인) 원고 에서이 패턴/스타일이 도메인 계층을 무지하게 유지하기 위해 저장소를 찾는 데 사용되는 공장을 사용하여 논의하고 설명합니다. 끈기있는 우려. (보다 23 장).

기본적 으로이 공장을 사용하면 예외가 발생합니다.

"저장소를 만드는 방법에 대한 지식은 공장과 함께 상주하지 않습니다.이 공장은 단지 저장소를 반환 할 수있는 능력을 나타냅니다."

이 예제는 저장소 인터페이스의 구체적인 구현을 초기화하기 위해 여러 메커니즘 중 하나를 사용했을 수 있습니다. 이 책의 예에서 그들은 단순성을 위해 IOC 컨테이너를 사용하지 않고 일부 시작 논리에서 명시 적으로 제공하지 않기로 선택합니다.

"중요한 점은 핵심 프로젝트 나 UI 프로젝트가 순전히 인프라 프로젝트 나 라이브러리를 순전히 인프라를 참조해서는 안된다는 것입니다. 우리는 나머지 응용 프로그램이 어떻게 데이터 액세스가 발생합니다. "

이 새로운 장에서 예제 코드에 대해 주목해야 할 마지막 요점은 공장이 더 이상 정적이지 않다는 것입니다 (적어도 외부 직면 인터페이스에 관한 한).

업데이트 2

Palermo 씨는 더 많은 것을 블로그에 올렸습니다 이 특별한 스타일의 추상 공장 (Ordershipperfactory의 구현을 참조하십시오).

나도 할 수 있었다 '수동 의존성 주입'을 고려하십시오. (밥 삼촌).

업데이트 3-3 월

거기 있습니다 그것의 또 다른 예, Jeffrey는 이것이 데모 코드에 대해 명시 적이지만, 주석은 이것이 Mark Seeman이 부르는 것에 대해 구성 될 것임을 나타냅니다. 구성 뿌리 (즉, 응용 프로그램 시작시)

Jeffrey의 기사에서 이것을 발견했습니다.양파 건축 : 4 부 - 4 년 후"

Answer 1

좋은 질문. 나도 좋아하지 않는다. 실제로 "startUpFactoryConfiguration"이라고 명명되어야하지만 리팩터 목록에 있습니다.

우리는 컨테이너를 통해 생성자 주입이 아닌 장소에 대한 DI를 설정하는 방법으로 그 아이디어를 가지고 놀았습니다.

사라질 것입니다. 나는 반포 반대가 무엇인지 모르겠지만 (어떤 이름?), 정전기가 죽을 것입니다.

---

이제 오늘 아침에 이름이 바뀌 었습니다. 이제 추상적 인기구입니다. 추상 공장 패턴의 구현입니다. http://en.wikipedia.org/wiki/abstract_factory_pattern

공장의 구현은 결국 IOC 제출자를 호출하는 것이지만, IOC 컨테이너 어셈블리에 대한 어셈블리 참조없이 코드의 장소에서 액세스 할 수 있습니다.

안부, Jeffrey Palermo

Answer 2

정적은 Di의 적입니다.

이 정전기는이 구현처럼 보입니다 서비스 로케이터 (항-) 패턴.

나는 서비스 로케이터가 API 사용자에게 의존성이 있어야하는 사람에게 완전히 불투명하기 때문에 반란 방지라고 생각합니다. 따라서 서비스 로케이터가 던지는 컨텍스트에서 객체에 대한 방법을 쉽게 호출 할 수 있으며 API는 이것이 사실이라는 단서를 전혀 제공하지 않습니다.

풍부한 사용과 같은 적절한 di 생성자 주입 훨씬 더 나은 대안입니다.