di 종속성 주입 구현의 중요성은 무엇입니까?

일반적인 PHP 프레임워크의 수명 주기는 다음과 같습니다. 요청 > 라우터/액션 > , 물론 약간의 차이는 있을 수 있지만 대부분은 이 정도에 지나지 않습니다.

디주사 도입의 의미는 무엇인가요? 디커플링을 달성하기 위해 응용 프로세스에 관련된 개체를 구성 요소로 설계하는 것입니까? RequestInterface/HttpRequest/CliRequest, RouterInterface/SimpleRouter/RegexRouter/MapRouter 등?

그러나 일반적인 요청 프로세스와 데이터베이스 작업은 모든 사람에게 동일합니다(ROR/J2EE/PHP MVC). 심지어 Restful에도 Router/Request/ControllerAction/Response가 있습니다. ? 해결한 후에도 여전히 꺼내서 MVC 프로세스를 구성해야 합니다. 라우터가 요청에 의존하는 것과 같으니 수동으로 주입하는 것은 어떻습니까? 라우터 생성자 매개변수는 RequestInterface $request인가요? 현재 애플리케이션 항목은 어떤 종류의 Request 객체를 삽입하기로 결정합니까? 언젠가 라우터가 이상한 장치에 의존하게 될 가능성이 있습니까?

그냥 조롱의 편의를 위한 걸까요? 아니면 불확실한 미래를 위한 것인가? 아니면 다른 이유가 있습니다. . .

답글 내용:

일반적인 PHP 프레임워크의 수명 주기는 다음과 같습니다. 요청 > 라우터/액션 > , 물론 약간의 차이는 있을 수 있지만 대부분은 이 정도에 지나지 않습니다.

디주사 도입의 의미는 무엇인가요? 디커플링을 달성하기 위해 응용 프로세스에 관련된 개체를 구성 요소로 설계하는 것입니까? RequestInterface/HttpRequest/CliRequest, RouterInterface/SimpleRouter/RegexRouter/MapRouter 등?

그러나 일반적인 요청 프로세스와 데이터베이스 작업은 모든 사람에게 동일합니다(ROR/J2EE/PHP MVC). 심지어 Restful에도 Router/Request/ControllerAction/Response가 있습니다. ? 해결한 후에도 여전히 꺼내서 MVC 프로세스를 구성해야 합니다. 라우터가 요청에 의존하는 것과 같으니 수동으로 주입하는 것은 어떻습니까? 라우터 생성자 매개변수는 RequestInterface $request인가요? 현재 애플리케이션 항목은 어떤 종류의 Request 객체를 삽입하기로 결정합니까? 언젠가 라우터가 이상한 장치에 의존하게 될 가능성이 있습니까?

그냥 조롱의 편의를 위한 걸까요? 아니면 불확실한 미래를 위한 것인가? 아니면 다른 이유가 있습니다. . .

DI에 대한 나의 견해는 항상 종속성 주입보다는 종속성 관리에 더 가깝다는 것입니다. 실제로 이는 애플리케이션과 라이브러리 간의 Composer, pip, Maven 및 기타 상위 수준 종속성 관리 도구와 유사합니다. 다음과 같은 이점을 제공합니다(좋은 DI 프레임워크 제공):

1. 구성을 통해 종속 인터페이스 구현을 변경하는 것도 DI 기능의 가장 기본이자 핵심 기능입니다

2. 싱글톤, 스레드당 하나, 요청당 하나 등 종속 구현의 인스턴스 범위를 유연하게 제어합니다.

3. 종속 매개변수, 종속 종속성 등 관리

4. 코드가 더 간결해지고 로직이 더 명확해졌습니다

5. Mock은 테스트하기 편리합니다. 1개로 하면 쉽습니다.

일반적으로 애플리케이션 내 함수 블록과 클래스 간의 종속성을 통일된 프레임워크를 통해 중앙에서 관리하는 것입니다.

그렇죠, 디커플링이죠.
MVC를 사용하여 디커플링이 완료되나요?
디커플링이 가장 낮은 수준인가요?

DI의 전제는 Bean을 호스팅하기 위한 통합 컨테이너가 필요하다는 것입니다. 이러한 컨테이너가 있으면 코드를 광범위하게 수정하지 않고도 내부 Bean에 대해 몇 가지 특별한 작업을 수행할 수 있습니다. ?

분리되어 단위 테스트에 편리한 명시적 주입은 관리하기가 더 쉽습니다. 가장 어려운 점은 소스 파일을 오랫동안 찾을 수 없는 암시적 주입입니다. Laravel의 DI는 실제로 요청과 서비스입니다.