Lang x Lang

Request Lifecycle

Table of Contents

Introduction

"実世界"で任意のツールを使用するとき、そのツールがどのように機能するのかを理解していると、自信を持って使用することができます。" Application " 開発も同様です。開発ツールの機能を理解すれば、それらを使用する際に自分自身がより快適で自信に満ちた状態になることができます。

このドキュメントの目的は、 Laravel フレームワークがどのように機能するかを、良く、高レベルで概観することです。フレームワーク全体をより理解することで、全てが"魔法のように"感じられることは減少し、あなたは自身のアプリケーションを構築する際により自信を持つことができます。すぐにすべての用語を理解できなくても気落ちしないでください!何が起こっているのかを基本的に把握しようと努めるだけで、他のドキュメンテーションのセクションを探索する中であなたの知識は増えていきます。

Lifecycle Overview

First Steps

すべての requests のエントリーポイントは、public/index.phpファイルです。すべての requests は、webserver(Apache / Nginx)の設定を通じてこのファイルに向けられます。index.phpファイルはあまり code を含んでいません。むしろ、それはフレームワークの残りの部分をロードするためのスタートポイントです。

index.phpファイルは、 Composer が生成した自動ローダーの定義を読み込み、その後bootstrap/app.phpからララベルの Laravel application のインスタンスを取得します。 Laravel 自体が最初に行う action は、 application / service containerのインスタンスを作成することです。

HTTP / Console カーネル

次に、着信する request は、handleRequestまたはhandleCommandメソッドを使用して、 application インスタンスの HTTP カーネルまたは console カーネルに送信されます。これは request が application に入る type によります。これらの 2 つのカーネルは、すべてのリクエストが流れる中心的な場所として機能します。今のところ、Illuminate\Foundation\Http\Kernelのインスタンスである HTTP カーネルに焦点を当てましょう。

HTTP カーネルは、request が実行される前に実行されるbootstrappersの array を定義します。これらのブートストラッパーは、error handling を設定、logging を設定、application 環境を検出します、そして request が実際に処理される前に行われる必要がある他のタスクを行います。通常、これらの classes は、あなたが心配する必要のない内部 Laravel 設定を handle します。

HTTP カーネルは、request を application の middlewarestack を通して伝達する役割を担っています。これらの middleware ハンドルは、HTTPsessionの読み取りと書き込み、application がメンテナンスモードにあるかどうかの判断、CSRFtoken の確認などを行います。これらについては後ほど詳しく説明します。

HTTP カーネルのhandle method の method シグネチャは非常にシンプルで、Requestを受け取り、Responseを返します。カーネルをあなたの全体の application を表す大きな黒いボックスと考えてみてください。それに HTTP requests を与えると、HTTP Response を返します。

Service Providers

カーネルブートストラップ作業の中で最も重要なものの一つは、あなたの application に対するService providersのロードです。 service providers は、 database 、 queue 、 validation 、そして routing コンポーネントなど、フレームワークの様々なコンポーネントをすべてブートストラップする責任を持っています。

Laravel はこの providers というリストを順次走査し、それぞれのインスタンスを生成します。それぞれの providers のインスタンスが生成された後、registerという method が全ての providers に対して呼び出されます。その後、すべての providers が登録されると、bootという method がそれぞれの provider に対して呼び出されます。これは、全ての service providers が、各自のboot method が実行される頃には、全てのコンテナバインディングが登録され利用可能であることに依存しているからです。

本質的には、 Laravel が提供する主な feature はすべて、 service provider によってブートストラップ化され、設定されます。彼らがフレームワークが提供する多くの features をブートストラップ化し、設定するため、 service providers は、 Laravel のブートストラップ process 全体で最も重要な側面です。

フレームワークは内部で数十の service providers を使用していますが、自分で作成するオプションもあります。ユーザー定義またはサードパーティの service providers のリストは、お使いの application で利用されているものが bootstrap/providers.php ファイルにあります。

Routing

application がブートストラップされ、すべての service providers が登録された後、Requestはルーターにディスパッチされるために引き渡されます。ルーターは request を route または controller に dispatch し、また route 固有の middleware を実行します。

Middleware は、あなたの application に入る HTTP requests をフィルタリングしたり検査したりする便利なメカニズムを提供します。例えば、 Laravel は、あなたの application の user が認証されているかどうかを確認する middleware を含んでいます。 user が認証されていない場合、 middleware は user をログイン画面に redirect します。しかし、 user が認証されている場合は、 middleware は request が application のさらに深い部分に進むことを許可します。一部の middleware は PreventRequestsDuringMaintenance のように、 application 内のすべての routes に割り当てられ、一部は特定の routes または route グループにのみ割り当てられます。 middleware については、完全な middleware documentationを読むことでより詳しく学ぶことができます。

もし request がマッチしたルートに割り当てられたすべての middleware を通過すると、その route または controller method が実行され、その route または controller method から返された response がルートの middleware チェーンを通じて返送されます。

仕上げ

route や controller method が response を返すと、その response は route の middleware を通じて外部に戻り、application が通信の response を変更したり、検査したりする機会をもらいます。

最後に、 response が middleware を通って戻ると、 handle という HTTP カーネルの method は response object を application インスタンスの handleRequestに返します。そして、この method は返された response に send の method を呼び出します。sendの method は response content をユーザーの web ブラウザに送信します。これで、我々は一連の Laravel request ライフサイクルを全て終えたことになります!

Focus on Service Providers

Service providers は、本当に Laravel application をブートストラップ化するための鍵です。 application インスタンスが作成され、 service providers が登録され、 request がブートストラップ化された application に渡されます。それは本当にそれほど単純なのです!

Laravel application がどのように構築され、 service providers を介してブートストラップ化されるかをしっかりと理解しておくことは非常に価値があります。 あなたのアプリケーションのユーザー定義の service providers は、app/Providersディレクトリに保存されています。

default では、AppServiceProviderはかなり空です。この provider は、application のブートストラップや service container のバインディングを追加するのに適しています。大規模な application の場合、application で使用される特定の services に対してより詳細なブートストラップを持つ複数の service providers を作成したいかもしれません。

当社サイトでは、Cookie を使用しています。各規約をご確認の上ご利用ください:
Cookie Policy, Privacy Policy および Terms of Use