コアポイント

• フロントエンドコントローラーは、アプリケーションの集中プロキシとして機(jī)能し、ページコントローラーやRESTリソースなどの事前定義されたハンドラーにコマンドを割り當(dāng)てます。
• フロントエンドコントローラーは、コンパクトな構(gòu)造を維持し、受信リクエストをルートおよびディスパッチすることができ、完全に機(jī)能的なRESTFULコントローラーに拡張し、HTTP動(dòng)詞を解析し、ディスパッチ前のフック前/ポストに適応することもできます。
この記事では、リクエスト/応答サイクルを個(gè)別に処理しながら、フロントエンドコントローラー、スタンドアロンルーター、およびスケジューラーで動(dòng)作する小型だがスケーラブルなHTTPフレームワークを展開する方法を示しています。
著者は、典型的なHTTP要求/応答サイクルのデータと動(dòng)作をシミュレートするクラスを定義し、ルーティングモジュールの構(gòu)築、スケジューラのセットアップなど、フロントエンドコントローラーをゼロから構(gòu)築するプロセスも導(dǎo)入しました。
フロントエンドコントローラーモードには、集中制御、コードの複製の削減、懸念のモジュール性と分離の改善の利點(diǎn)がありますが、すべてのWebアプリケーションに適していない場合があり、不適切に実裝された場合、単一の障害點(diǎn)になる可能性があります。

フロントエンドコントローラーはアプリケーションの集中プロキシのようなものであり、その主な焦點(diǎn)は、ページコントローラー、休憩リソース、または頭に浮かぶ他のものなどの事前定義されたハンドラーにコマンドを靜的または動(dòng)的に割り當(dāng)てることです。 。少なくとも1つのシンプルなフロントエンドコントローラーを構(gòu)築することは、その詳細(xì)を理解し、実用的な観點(diǎn)からこのアイデアを促進(jìn)するための非常に便利な體験です。リクエストを発送するために必要なすべてのロジックは、クラスの境界內(nèi)にパッケージ化されます。フロントエンドコントローラーの最良の側(cè)面の1つは、コンパクトな構(gòu)造、ルートおよびディスパッチの受信要求のみを維持できることです。または、創(chuàng)造性を表示し、HTTP動(dòng)詞を解析できる完全に機(jī)能的なRESTFULコントローラーを?qū)g裝できることです。フックなど、すべて統(tǒng)一されたAPIの後ろに。ただし、このアプローチは魅力的ですが、単一の責(zé)任原則（SRP）とOOP自體の性質(zhì)に違反し、さまざまなタスクを複數(shù)の細(xì)かいオブジェクトに積極的に委任します。それで、これは私がSRPの教訓(xùn)を壊すことを敢えてするもう一つの罪深い魂であることを意味しますか？ある意味では、はい。そのため、スタンドアロンのルーターとスケジューラーを備えたフロントエンドコントローラーと連攜できる小型でスケーラブルなHTTPフレームワークを簡単に展開する方法を示すことで、罪を排除したいと思います。さらに、要求/応答サイクル全體は、自然に自然に調(diào)整できるいくつかの再利用可能なクラスによって獨(dú)立して処理されます。多數(shù)の完全に食べられたコンポーネントパッケージ化されたHTTPフレームワークが利用可能であることを考えると、これらのクラスがSRPの性質(zhì)を保持していても、リクエストをゼロからルーティングしてディスパッチするフロントエンドコントローラーを?qū)g裝することはばかげているようです。ホイールを再発明するために判斷されることを避けるために、私のカスタム実裝の一部は、Lars Strojnyが書いた巧妙なEphpMVCライブラリに觸発されます。

リクエスト/ルーティング/スケジューリング/応答サイクルを分析します

最初に解決する必要があるタスクは、典型的なHTTP要求/応答サイクルのデータと動(dòng)作をシミュレートする責(zé)任のあるいくつかのクラスを定義することです。これは最初のクラスであり、それが実裝するインターフェイスです：

<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>

リクエストクラスは、著信URIとパラメーター配列をカプセル化し、非常にシンプルなHTTP要求をシミュレートします。簡潔にするために、関連する要求に関連付けられたメソッドセットなどの追加データメンバーは意図的に除外されています。クラスに追加したい場合は、続行してください。獨(dú)立して存在する薄いHTTP要求ラッパーを使用することは良いことですが、典??型的なHTTP応答をシミュレートするデータと動(dòng)作の対応する部分と結(jié)合することなく役に立たなくなります。この補(bǔ)足コンポーネントを修正して構(gòu)築しましょう：

<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>

応答クラスは、パートナーリクエストよりも間違いなくアクティブです。これは、HTTPヘッダーを自由にスタックできるベースコンテナとして機(jī)能し、クライアントに送信できるようにします。これらのクラスは獨(dú)立して操作を?qū)g行するため、フロントエンドコントローラーの次の部分の構(gòu)築を開始する時(shí)が來ました。典型的な実裝では、ルーティング/ディスパッチプロセスはほとんど同じアプローチでカプセル化されており、率直に言ってそれほど悪くはありません。ただし、この場合、これらのプロセスを分解して、異なるクラスに委任する方が良いでしょう。このようにして、物事は平等な責(zé)任の點(diǎn)でよりバランスが取れます。ルーティングモジュールを?qū)g行するクラスのバッチは次のとおりです。

予想されるように、機(jī)能的なルーティングメカニズムを?qū)g裝する際には多くのオプションがあります。少なくとも私の意見では、上記の方法は実用的で直接的です。特定の操作コントローラーへのパスをバインドする個(gè)別のルートクラスと、責(zé)任が特定のリクエストオブジェクトに関連付けられたURIと一致するかどうかを確認(rèn)することに責(zé)任が限定されている?yún)g純なルーターを定義します。最後に問題を解決するには、前のクラスと並んで使用できるクイックスケジューラを設(shè)定する必要があります。これは、次のクラスがどのように行うかです：

<code>class Route {

  public function __construct($path, $controllerClass) {
    $this->path = $path;
    $this->controllerClass = $controllerClass;
  }

  public function match(RequestInterface $request) {
    return $this->path === $request->getUri();
  }

  public function createController() {
   return new $this->controllerClass;
  }
}


class Router {
  public function __construct($routes) {
    $this->addRoutes($routes);
  }

  public function addRoute(RouteInterface $route) {
    $this->routes[] = $route;
    return $this;
  }

  public function addRoutes(array $routes) {
    foreach ($routes as $route) {
      $this->addRoute($route);
    }
    return $this;
  }

  public function getRoutes() {
    return $this->routes;
  }

  public function route(RequestInterface $request, ResponseInterface $response) {
    foreach ($this->routes as $route) {
      if ($route->match($request)) {
        return $route;
      }
    }
    $response->addHeader("404 Page Not Found")->send();
    throw new \OutOfRangeException("No route matched the given URI.");
  }
}</code>

ディスパッチャーをスキャンすると、2つのことがわかります。第一に、それはいかなる狀態(tài)でもありません。第二に、各操作コントローラーがexecute（）メソッドの表面の下で実行されることを暗黙的に想定しています。これは、必要に応じてやや柔軟なパターンにリファクタリングできます（最初に頭に浮かぶのは、ルートクラスの実裝を微調(diào)整することです）が、簡単にするために、スケジューラを変更せずに保ちます。これまでのところ、以前のすべてのクラスを組み合わせることができるフロントエンドコントローラーをどのように配置するか疑問に思うかもしれません。心配しないでください、次はそうです！

<code>class Dispatcher {

  public function dispatch($route, $request, $response)
    $controller = $route->createController();
    $controller->execute($request, $response);
  }
}</code>

（スペースの制限により、後続のコンテンツは切り捨てられます。殘りのコンテンツを提供してください。擬似オリジナルを完了し続けます。）

以上がフロントコントローラーパターンの紹介、パート2の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。