核心要點(diǎn)

• 前端控制器充當(dāng)應(yīng)用程序的集中式代理，將命令分派給預(yù)定義的處理程序，例如頁面控制器或 REST 資源。
• 前端控制器可以保持緊湊的結(jié)構(gòu)，路由和分派傳入請(qǐng)求，也可以擴(kuò)展為功能齊全的 RESTful 控制器，解析 HTTP 動(dòng)詞，適應(yīng)預(yù)/後分派鉤子等。
• 本文演示瞭如何部署一個(gè)小型但可擴(kuò)展的 HTTP 框架，該框架能夠與前端控制器、獨(dú)立路由器和調(diào)度程序一起工作，同時(shí)獨(dú)立處理請(qǐng)求/響應(yīng)週期。
• 作者還介紹了從頭開始構(gòu)建前端控制器的過程，包括定義類來模擬典型 HTTP 請(qǐng)求/響應(yīng)週期的數(shù)據(jù)和行為，構(gòu)建路由模塊以及設(shè)置調(diào)度程序。
• 前端控制器模式具有集中控制、減少代碼重複以及改進(jìn)模塊化和關(guān)注點(diǎn)分離等優(yōu)點(diǎn)，但它可能不適用於所有 Web 應(yīng)用程序，如果實(shí)現(xiàn)不當(dāng)，可能會(huì)導(dǎo)致單點(diǎn)故障。

前端控制器就像應(yīng)用程序中的集中式代理，其主要關(guān)注領(lǐng)域是靜態(tài)或動(dòng)態(tài)地將命令分派給預(yù)定義的處理程序，例如頁面控制器、REST 資源或任何其他想到的東西。構(gòu)建至少一個(gè)簡(jiǎn)單的前端控制器是理解其細(xì)節(jié)的非常有益的經(jīng)驗(yàn)，為了從務(wù)實(shí)的角度推廣這一想法，我在介紹性文章中介紹了一個(gè)人為的前端控制器的實(shí)現(xiàn)，該控制器將路由和分派請(qǐng)求所需的所有邏輯打包在一個(gè)類的邊界內(nèi)。前端控制器最好的方面之一是您可以將它們保持為緊湊的結(jié)構(gòu)，只路由和分派傳入請(qǐng)求，或者您可以展現(xiàn)您的創(chuàng)造力，並實(shí)現(xiàn)一個(gè)功能齊全的RESTful 控制器，能夠解析HTTP動(dòng)詞，適應(yīng)預(yù)/後分派鉤子等等，所有這些都在統(tǒng)一的API 後面。但是，雖然這種方法很有吸引力，但它違反了單一職責(zé)原則 (SRP) 並違背了 OOP 本身主動(dòng)將不同任務(wù)委託給多個(gè)細(xì)粒度對(duì)象的本質(zhì)。那麼，這是否意味著我只是另一個(gè)膽敢違反 SRP 戒律的有罪靈魂呢？從某種意義上說，是的。因此，我想通過向您展示如何輕鬆部署一個(gè)小型但可擴(kuò)展的 HTTP 框架來消除我的罪惡，該框架能夠與獨(dú)立路由器和調(diào)度程序一起使用前端控制器。此外，整個(gè)請(qǐng)求/響應(yīng)週期將由幾個(gè)可重用的類獨(dú)立處理，這些類自然可以隨意調(diào)整。鑑於有大量功能齊全的組件打包的 HTTP 框架可用，從頭開始實(shí)現(xiàn)一個(gè)通過幾個(gè)模塊化類路由和分派請(qǐng)求的前端控制器似乎很荒謬，即使這些類保留了 SRP 的本質(zhì)。為了避免因重新發(fā)明輪子而受到評(píng)判，我的自定義實(shí)現(xiàn)的一些部分將受到 Lars Strojny 編寫的巧妙的 EPHPMVC 庫的啟發(fā)。

剖析請(qǐng)求/路由/分派/響應(yīng)週期

我們應(yīng)該首先解決的任務(wù)是定義幾個(gè)負(fù)責(zé)模擬典型 HTTP 請(qǐng)求/響應(yīng)週期的數(shù)據(jù)和行為的類。這是第一個(gè)類，以及它實(shí)現(xiàn)的接口：

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

Request 類封裝了傳入的 URI 和參數(shù)數(shù)組，並模擬了一個(gè)極其簡(jiǎn)單的 HTTP 請(qǐng)求。為簡(jiǎn)潔起見，諸如與相關(guān)請(qǐng)求關(guān)聯(lián)的方法集之類的附加數(shù)據(jù)成員已故意排除在外。如果您想將它們添加到類中，請(qǐng)繼續(xù)操作。擁有一個(gè)獨(dú)立存在的精簡(jiǎn) HTTP 請(qǐng)求包裝器很好，但如果沒有與模擬典型 HTTP 響應(yīng)的數(shù)據(jù)和行為的對(duì)應(yīng)部分耦合，最終將毫無用處。讓我們修復(fù)並構(gòu)建這個(gè)補(bǔ)充組件：

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

Response 類無疑比其夥伴 Request 更活躍。它充當(dāng)一個(gè)基本容器，允許您隨意堆疊 HTTP 標(biāo)頭，並且能夠?qū)⑺鼈儼l(fā)送到客戶端。由於這些類獨(dú)立地執(zhí)行其操作，因此是時(shí)候著手構(gòu)建前端控制器的下一部分了。在典型的實(shí)現(xiàn)中，路由/分派過程大多數(shù)情況下封裝在相同的方法中，坦白地說，這根本不算太壞。但是，在這種情況下，最好將這些過程分解並將其委託給不同的類。這樣，事情在責(zé)任平等方面會(huì)更加平衡。以下是使路由模塊運(yùn)行的類批次：

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

正如人們可能預(yù)期的那樣，在實(shí)現(xiàn)功能性路由機(jī)制時(shí)，有很多選擇。至少在我看來，上述方法既實(shí)用又直接。它定義了一個(gè)獨(dú)立的 Route 類，該類將路徑綁定到給定的操作控制器，以及一個(gè)簡(jiǎn)單的路由器，其職責(zé)僅限於檢查存儲(chǔ)的路由是否與特定請(qǐng)求對(duì)象關(guān)聯(lián)的 URI 匹配。為了最終解決問題，我們需要設(shè)置一個(gè)快速調(diào)度程序，可以與之前的類並排使用。下面的類就是這樣做的：

<code>class Dispatcher {

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

掃描 Dispatcher，您會(huì)注意到兩件事。首先，它不攜帶任何狀態(tài)。其次，它隱式地假設(shè)每個(gè)操作控制器都將在 execute() 方法的表面下運(yùn)行。如果您願(yuàn)意，這可以被重構(gòu)為稍微更靈活的模式（我首先想到的是調(diào)整 Route 類的實(shí)現(xiàn)），但為了簡(jiǎn)單起見，我將保持調(diào)度程序不變。到目前為止，您可能想知道如何在何處放置能夠?qū)⑺邢惹邦惤M合在一起的前端控制器。別著急，接下來就是！

(由於篇幅限制，後續(xù)內(nèi)容將被截?cái)?。?qǐng)?zhí)峁┦ｐN部分，我將繼續(xù)完成偽原創(chuàng)。)

以上是前控制器圖案的簡(jiǎn)介，第2部分的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！