Pengenalan kepada Corak Pengawal Depan, Bahagian 2

mata teras

Pengawal depan bertindak sebagai proksi terpusat untuk permohonan itu, memberikan arahan kepada pengendali yang telah ditetapkan, seperti pengawal halaman atau sumber rehat.
Pengawal depan boleh mengekalkan struktur padat, laluan dan penghantaran permintaan masuk, dan juga boleh diperluaskan kepada pengawal yang berfungsi sepenuhnya, menghuraikan kata kerja HTTP, menyesuaikan diri dengan cangkuk pra/posting, dan lain-lain.
Artikel ini menunjukkan bagaimana untuk menggunakan rangka kerja HTTP yang kecil tetapi berskala yang berfungsi dengan pengawal front-end, router mandiri, dan penjadual semasa mengendalikan kitaran permintaan/tindak balas secara bebas.
Penulis juga memperkenalkan proses membina pengawal front-end dari awal, termasuk menentukan kelas untuk mensimulasikan data dan tingkah laku kitaran permintaan/tindak balas HTTP yang tipikal, modul penghalaan bangunan, dan menubuhkan penjadual.
Mod pengawal front-end mempunyai kelebihan kawalan berpusat, mengurangkan duplikasi kod, dan meningkatkan modulariti dan pemisahan kebimbangan, tetapi mungkin tidak sesuai untuk semua aplikasi web dan mungkin mengakibatkan satu titik kegagalan jika dilaksanakan secara tidak wajar.

Pengawal Front-end adalah seperti proksi berpusat dalam aplikasi, dan bidang tumpuan utamanya adalah untuk memberikan arahan secara statistik atau dinamik kepada pengendali yang telah ditetapkan seperti pengawal halaman, sumber rehat, atau apa-apa lagi yang datang ke fikiran . Membina sekurang-kurangnya satu pengawal front-end yang mudah adalah pengalaman yang sangat berguna untuk memahami butirannya, dan untuk mempromosikan idea ini dari sudut pandangan pragmatik, saya memperkenalkan dalam pos pengantar pelaksanaan pengawal front-end buatan yang akan mengarahkan dan Semua logik yang diperlukan untuk menghantar permintaan dibungkus dalam sempadan kelas. Salah satu aspek terbaik pengawal front-end ialah anda boleh memastikan mereka sebagai struktur padat, laluan dan penghantaran permintaan masuk sahaja, atau anda boleh menunjukkan kreativiti anda dan melaksanakan pengawal yang berfungsi sepenuhnya berfungsi cangkuk penghantaran, dan lain -lain, semua di belakang API bersatu. Walau bagaimanapun, sementara pendekatan ini menarik, ia melanggar prinsip tanggungjawab tunggal (SRP) dan sifat OOP itu sendiri secara proaktif mewakilkan tugas yang berbeza kepada pelbagai objek yang halus. Jadi, adakah ini bermakna saya hanya satu lagi jiwa berdosa yang berani memecahkan ajaran SRP? Dalam erti kata, ya. Oleh itu, saya ingin menghapuskan dosa saya dengan menunjukkan kepada anda bagaimana dengan mudah menggunakan kerangka HTTP yang kecil tetapi berskala yang dapat bekerja dengan pengawal front-end dengan router dan penjadual yang berdiri sendiri. Di samping itu, keseluruhan kitaran permintaan/tindak balas akan dikendalikan secara bebas oleh beberapa kelas yang boleh diguna semula yang secara semulajadi boleh diselaraskan mengikut kehendak. Memandangkan terdapat sejumlah besar rangka kerja HTTP yang disapu komponen yang disediakan sepenuhnya, nampaknya tidak masuk akal untuk melaksanakan pengawal front-end bahawa laluan dan menghantar permintaan dari awal walaupun kelas-kelas ini mengekalkan sifat SRP. Untuk mengelakkan dihakimi untuk mencipta semula roda, beberapa bahagian pelaksanaan adat saya akan diilhamkan oleh perpustakaan EphPMVC pintar yang ditulis oleh Lars Strojny.

Analisis permintaan/routing/penjadualan/kitaran tindak balas

Tugas yang harus kita selesaikan terlebih dahulu adalah untuk menentukan beberapa kelas yang bertanggungjawab untuk mensimulasikan data dan tingkah laku kitaran permintaan/tindak balas HTTP biasa. Ini adalah kelas pertama, dan antara muka yang dilaksanakan:

Kelas permintaan yang merangkumi pelbagai URI dan parameter yang masuk dan mensimulasikan permintaan HTTP yang sangat mudah. Bagi keringkasan, ahli data tambahan seperti kaedah yang berkaitan dengan permintaan yang berkaitan telah sengaja dikecualikan. Jika anda mahu menambahkannya ke kelas, teruskan. Mempunyai pembalut permintaan HTTP yang nipis yang wujud secara bebas adalah baik, tetapi ia akan menjadi sia -sia tanpa gandingan dengan bahagian data dan tingkah laku yang sama yang menyerupai tindak balas HTTP yang tipikal. Mari Betulkan dan Bina Komponen Tambahan ini:

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

Kelas tindak balas tidak diragukan lagi lebih aktif daripada permintaan rakan kongsi. Ia bertindak sebagai bekas asas yang membolehkan anda menyusun tajuk HTTP di Will dan dapat menghantarnya kepada pelanggan. Oleh kerana kelas-kelas ini menjalankan operasi mereka secara bebas, sudah tiba masanya untuk mula membina bahagian seterusnya pengawal hadapan. Dalam pelaksanaan biasa, proses penghalaan/penghantaran kebanyakannya dikemas dalam pendekatan yang sama, yang terus terang tidak terlalu buruk sama sekali. Walau bagaimanapun, dalam kes ini, lebih baik untuk memecahkan proses ini dan mewakilkannya ke kelas yang berbeza. Dengan cara ini, perkara akan lebih seimbang dari segi tanggungjawab yang sama. Berikut adalah kumpulan kelas yang membuat modul penghalaan dijalankan:

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

seperti yang diharapkan, terdapat banyak pilihan ketika melaksanakan mekanisme penghalaan berfungsi. Sekurang -kurangnya pada pendapat saya, kaedah di atas adalah praktikal dan langsung. Ia mentakrifkan kelas laluan berasingan yang mengikat laluan ke pengawal operasi yang diberikan, dan penghala mudah yang tanggungjawabnya terhad untuk memeriksa sama ada laluan yang disimpan sepadan dengan URI yang berkaitan dengan objek permintaan tertentu. Untuk akhirnya menyelesaikan masalah ini, kita perlu menyediakan penjadual cepat yang boleh digunakan bersebelahan dengan kelas sebelumnya. Ini adalah bagaimana kelas berikut:

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

Imbas pengirim dan anda akan melihat dua perkara. Pertama, ia tidak membawa negeri. Kedua, secara tersirat mengandaikan bahawa setiap pengawal operasi akan berjalan di bawah permukaan kaedah pelaksanaan (). Ini boleh refactored kepada corak yang lebih fleksibel jika anda mahu (perkara pertama yang masuk ke dalam fikiran adalah untuk mengubahsuai pelaksanaan kelas laluan), tetapi untuk kesederhanaan, saya akan mengekalkan penjadual tidak berubah. Setakat ini, anda mungkin tertanya-tanya bagaimana untuk meletakkan pengawal front-end yang dapat menggabungkan semua kelas sebelumnya bersama-sama. Jangan risau, seterusnya!

<code>class Dispatcher {

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

(disebabkan oleh batasan ruang, kandungan berikutnya akan dipotong. Sila berikan kandungan yang lain dan saya akan terus melengkapkan pseudo-asal.)

Atas ialah kandungan terperinci Pengenalan kepada Corak Pengawal Depan, Bahagian 2. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!