2012-11-06 2 views
13

ServiceManager 일 때 DI은 무엇이고 사용 사례는 무엇입니까?Zend Di와 ServiceManager 종속성 주입 컨테이너

zend-dizend-servicemanager에 대한 구성 파일에서 우리는 aliasesinvokables과 같은 몇 가지 옵션을 설정할 수 있으므로 비슷한 것으로 보입니다.

나는이 구성 요소로 어떤 일이 일어나고 있는지 잘 이해하려고 노력하고 있으며, 문서화로 충분한 정보를 얻지 못했습니다.

ServiceManager 대신 Di을 사용해야하는 이유는 무엇입니까?

+0

일반적으로 컨테이너에 대한 좋은 토론에있다가 http://www.php-fig.org/psr/psr-11/meta/ – Dennis

+0

현대 조언은 "DI 또는 SM을 사용하지 말 것"인 것처럼 보이지만, 그들이 이미 프레임 워크의 일부가 아니라면. Zend는 팩토리 기반 서비스 관리자 (본질적으로 제한된 DI 컨테이너 임)를 사용합니다. 여기서 사용자는 모든 컨테이너를 자신의 클래스에 삽입하지 않고 *주의해야합니다. 그러나 컨테이너를 자신의 클래스 세트의 일부로 사용할 수 있습니다. 신청. 즉 Zend에서 프레임 워크 자체의 기능을 사용하여 종속성이 어떻게 연결되는지 사용자 정의 할 수 있습니다. 최근의 예제는 다음과 같습니다. https://docs.zendframework.com/tutorials/getting-started/database-and-models/ – Dennis

답변

15

Zend \ DI는 반사처럼 마법을 사용하여 서비스 관리자가 사용자 제공 공장을 사용하는 동안 종속성을 감지하고 주입합니다. 그것은 주요 차이점입니다.

복잡성, 디버깅 및 성능 문제로 인해 SM에 찬성하여 커뮤니티에서 더 이상 사용되지 않습니다. RAD에 좋을 것으로 생각되지만, 제대로 사용하려면 평균 이상의 지식이 필요합니다.

반면에 SM은 매우 상세하고 명확한 배선을 가지고 있습니다. 나중에 코드를 열어서 무슨 일이 일어나는지 쉽게 알아낼 수 있습니다.

+1

좋은 답변입니다. 초기에 DI를 사용했던 것을 기억하고 있습니다. 다시 사용하지 않을 것입니다. . – DrBeza

+0

그것은 내가 di를 사용하는 것을 거부 할 수 있음을 의미합니까? sm도 작업을 수행 할 것입니까? – user1650441

+0

정확히 Xerkus가 지적했듯이. 디 - 스터프 (Di-Stuff)는 꽤 많은 양의 모욕적 인 것으로 간주되며, DI 컨테이너는 지나치게 복잡합니다. ServiceManager는 훨씬 더 사용자 친화적 인 방식으로 동일한 핵심 문제를 해결합니다. – Sam

6

Zend\Di은 클래스를 함께 연결하는 반면, Zend\ServiceManager을 사용하면 수동으로 연결하고 인스턴스화하려는 모든 클래스에 대해 공장 폐쇄를 작성해야합니다.

Zend\ServiceManager은 느린 Reflection API에 의존하지 않기 때문에 훨씬 빠릅니다. 반면에 수백 개의 클래스가있는 대규모 응용 프로그램의 클로저 작성은 매우 지루한 작업입니다. 응용 프로그램이 커짐에 따라 클로저를 최신 상태로 유지하는 것이 더 까다로워집니다.

이 문제를 해결하기 위해 ZendDiCompiler이라는 Zend Framework 2 모듈을 작성했습니다. Zend\Di을 사용하여 코드를 스캔 한 다음 공장 코드를 자동 생성하여 클래스를 인스턴스화합니다. Zend\Di의 성능과 Zend\ServiceManager의 성능을 모두 얻을 수 있습니다.

ZendDiCompiler의 문서에 상당히 많은 작업을했으며 몇 가지 쉽고 고급적인 사용 예제도 제공됩니다.

0

는 기본적으로 차이는 다음과 같다 :

  • Zend\ZerviceManager IOC의 컨테이너를 구동 = 공장
  • Zend\Di = Autowiring은 IOC의 구현

Zend\Di은 버전 3에 대한 리팩토링했다 그것의 행동을 더욱 견고하고, v2보다 예측 가능하며 zend-servicemanager에 완벽하게 통합되어 자동 배선 기능을 제공합니다 (이상한 마술은 아닙니다). 종속성을 해결하기 위해 PHP의 리플렉션 API를 사용하기 때문에 공장 주도 방식보다 느립니다. 따라서 버전 3에는 AoT 컴파일러가 포함되어 Reflection의 사용을 생략 한 사전 해결 된 인젝터를 만듭니다. 추가 혜택 : 생성 된 공장을 Zend\ServiceManager과 직접 사용할 수도 있습니다.

두 구성 요소와 AOT를 사용하기위한 가이드가

: https://zendframework.github.io/zend-di/cookbook/aot-guide/