전면 컨트롤러 패턴 소개, 2 부

코어 포인트

프론트 엔드 컨트롤러는 애플리케이션의 중앙 중앙 프록시 역할을하며 페이지 컨트롤러 또는 REST 리소스와 같은 사전 정의 된 핸들러에 명령을 할당합니다.

프론트 엔드 컨트롤러는 소형 구조, 경로 및 파견 요청을 유지할 수 있으며, 완전히 기능적인 RESTFUL 컨트롤러, PARSE HTTP 동사, 사전/사후 디스패치 후크 등으로 확장 할 수 있습니다.

이 기사는 독립적으로 요청/응답주기를 처리하는 동안 프론트 엔드 컨트롤러, 독립형 라우터 및 스케줄러와 함께 작동하는 작지만 확장 가능한 HTTP 프레임 워크를 배포하는 방법을 보여줍니다.
• 저자는 또한 일반적인 HTTP 요청/응답주기의 데이터 및 동작을 시뮬레이션하고 라우팅 모듈 구축 및 스케줄러 설정을 포함하여 클래스 정의를 포함하여 프론트 엔드 컨트롤러를 처음부터 구축하는 프로세스를 처음부터 도입했습니다.
프론트 엔드 컨트롤러 모드는 중앙 집중식 제어의 장점, 코드 복제 감소 및 우려의 모듈성 및 분리 개선이 있지만 모든 웹 애플리케이션에 적합하지는 않으며 부적절하게 구현하면 단일 고장을 초래할 수 있습니다.
프론트 엔드 컨트롤러는 애플리케이션의 중앙 집중식 프록시와 같으며, 주요 초점 영역은 페이지 컨트롤러, REST 리소스 또는 마음에 떠오르는 기타와 같은 사전 정의 된 핸들러에 정적 또는 동적으로 명령을 할당하는 것입니다. . 적어도 하나의 간단한 프론트 엔드 컨트롤러를 구축하는 것은 세부 사항을 이해하고 실용적인 관점 에서이 아이디어를 홍보하는 데 매우 유용한 경험입니다. 요청을 발송하는 데 필요한 모든 논리는 클래스의 경계 내에서 포장됩니다. 프론트 엔드 컨트롤러의 가장 좋은 측면 중 하나는 소형 구조, 경로 및 파견 요청 만으로만 유지하거나 창의성을 보여주고 HTTP 동사, 적응 사전/게시물을 구문 분석 할 수있는 완전한 기능적인 편안한 컨트롤러를 구현할 수 있다는 것입니다. Unified API 뒤에 모든 디스패치 후크 등. 그러나이 접근법은 매력적이지만 SRP (Single Responsibility Principle)와 OOP 자체의 특성을 여러 번 세분화 된 물체에 대해 다른 작업을 적극적으로 위임합니다. 그래서 이것은 내가 SRP 교훈을 깨는 것을 감히하는 또 다른 죄 많은 영혼이라는 것을 의미합니까? 어떤 의미에서, 그렇습니다. 따라서 독립형 라우터 및 스케줄러가있는 프론트 엔드 컨트롤러와 함께 작업 할 수있는 작지만 확장 가능한 HTTP 프레임 워크를 쉽게 배포하는 방법을 보여줌으로써 죄를 제거하고 싶습니다. 또한 전체 요청/응답주기는 자연스럽게 자연스럽게 조정할 수있는 여러 재사용 클래스에 의해 독립적으로 처리됩니다. 사용 가능한 완전 기능이 풍부한 구성 요소가 포장 된 HTTP 프레임 워크가 많다는 점을 감안할 때, 이러한 클래스가 SRP의 특성을 유지하더라도 처음부터 요청을 라우팅하고 발송하는 프론트 엔드 컨트롤러를 구현하는 것은 우스운 것처럼 보입니다. 휠 재창조로 판단되는 것을 피하기 위해 내 맞춤형 구현의 일부는 Lars Strojny가 작성한 영리한 EPHPMVC 라이브러리에서 영감을받습니다.

• 요청/라우팅/스케줄링/응답주기 분석 먼저 해결해야 할 작업은 일반적인 HTTP 요청/응답주기의 데이터 및 동작을 시뮬레이션하는 여러 클래스를 정의하는 것입니다. 이것은 첫 번째 클래스이며 인터페이스 IT는 다음과 같습니다.

  요청 클래스는 수신 URI 및 매개 변수 배열을 캡슐화하고 매우 간단한 HTTP 요청을 시뮬레이션합니다. 간결성의 경우, 관련 요청과 관련된 메소드 세트와 같은 추가 데이터 구성원이 의도적으로 제외되었습니다. 수업에 추가하려면 계속하십시오. 독립적으로 존재하는 얇은 HTTP 요청 래퍼를 갖는 것은 좋지만, 일반적인 HTTP 응답을 시뮬레이션하는 데이터 및 동작의 해당 부분과 결합하지 않고 쓸모가 없을 것입니다. 이 보충 구성 요소를 수정하고 구축합시다

  응답 클래스는 의심 할 여지없이 파트너 요청보다 더 활발합니다. HTTP 헤더를 마음대로 쌓을 수있는 기본 컨테이너 역할을하고 클라이언트에게 보낼 수 있습니다. 이 클래스는 독립적으로 작업을 수행하므로 프론트 엔드 컨트롤러의 다음 부분을 구축하기 시작할 때입니다. 일반적인 구현에서 라우팅/디스패치 프로세스는 대부분 동일한 접근법으로 캡슐화되며 솔직히 전혀 나쁘지 않습니다. 그러나이 경우 이러한 프로세스를 분해하여 다른 클래스로 위임하는 것이 좋습니다. 이런 식으로, 동등한 책임 측면에서 상황이 더 균형을 이룰 것입니다. 다음은 라우팅 모듈을 실행하는 클래스의 배치입니다.

  예상대로 기능적 라우팅 메커니즘을 구현할 때 많은 옵션이 있습니다. 적어도 제 생각에는 위의 방법은 실용적이고 직접적입니다. 주어진 조작 컨트롤러로 경로를 바인딩하는 별도의 경로 클래스와 저장된 경로가 특정 요청 개체와 관련된 URI와 일치하는지 확인하는 책임이있는 간단한 라우터를 정의합니다. 마지막으로 문제를 해결하려면 이전 클래스와 나란히 사용할 수있는 빠른 스케줄러를 설정해야합니다. 이것이 다음 수업이하는 방식입니다 :

  <code>class Request {
  
    public function __construct($uri, $params) { 
      $this->uri = $uri;
      $this->params = $params;
    }
  
    public function getUri() {
      return $this->uri;
    }
  
    public function setParam($key, $value) {
      $this->params[$key] = $value;
      return $this;
    }
  
    public function getParam($key) {
      if (!isset($this->params[$key])) {
        throw new \InvalidArgumentException("The request parameter with key '$key' is invalid."); 
      }
      return $this->params[$key];
    }
  
    public function getParams() {
      return $this->params;
    }
  }</code>

  디스패처를 스캔하면 두 가지가 나타납니다. 첫째, 어떤 상태도 가지고 있지 않습니다. 둘째, 각 조작 컨트롤러가 Execute () 메소드의 표면 아래에서 실행된다고 가정합니다. 원하는 경우 (가장 먼저 떠오르는 것은 경로 클래스의 구현을 조정하는 것입니다), 이는 단순화를 위해 스케줄러를 변경하지 않도록하겠습니다. 지금까지 이전 클래스를 결합 할 수있는 프론트 엔드 컨트롤러를 배치하는 방법이 궁금 할 것입니다. 걱정하지 마세요, 다음은!

  <code>class Response {
    public function __construct($version) {
      $this->version = $version;
    }
  
    public function getVersion() {
      return $this->version;
    }
  
    public function addHeader($header) {
      $this->headers[] = $header;
      return $this;
    }
  
    public function addHeaders(array $headers) {
      foreach ($headers as $header) {
        $this->addHeader($header);
      }
      return $this;
    }
  
    public function getHeaders() {
      return $this->headers;
    }
  
    public function send() {
      if (!headers_sent()) {
        foreach($this->headers as $header) {
          header("$this->version $header", true);
        }
      } 
    }
  }</code>

  (공간 제한으로 인해 후속 컨텐츠가 잘릴 것입니다. 나머지 내용을 제공하면 유사 원리를 계속 완료 할 것입니다.)

위 내용은 전면 컨트롤러 패턴 소개, 2 부의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!