イントロダクションIntroduction
「現実の世界」でツールを使用する場合、その道具がどのように動作するかを理解しておいたほうが、自信が持てます。アプリケーションの開発も違いはありません。開発ツールがどのように働くのかを理解すれば、より快適に自信を持って使用できるのです。When using any tool in the "real world", you feel more confident if you understand how that tool works. Application development is no different. When you understand how your development tools function, you feel more comfortable and confident using them.
このドキュメントの目的は、どのようにLaravelが「働いて」いるのか、ハイレベルな概念を理解してもらうためです。フレームワークの概念をより良く知ってもらうことで、全てに対し「不可解さ」が減り、より自信を持ってアプリケーションを開発してもらえます。The goal of this document is to give you a good, high-level overview of how the Laravel framework "works". By getting to know the overall framework better, everything feels less "magical" and you will be more confident building your applications.
これらの言葉を今すぐ理解できなくても、気落ちしないで下さい。ただ、何が行われているかを理解するための基本だけを理解してください。ドキュメントの他のセクションで明確にされる内容を理解すれば、知識は育っていくことでしょう。If you don't understand all of the terms right away, don't lose heart! Just try to get a basic grasp of what is going on, and your knowledge will grow as you explore other sections of the documentation.
概論Lifecycle Overview
始まりFirst Things
アプリケーションに対するリクエストは、全てpublic/index.php
ファイルが入り口になります。Webサーバー(Apache/Nginx)の設定により、全てのリクエストをこのファイルへ渡しています。index.php
ファイルは、さほどコードを持っていません。フレームワークの残りをロードするための入り口にすぎません。The entry point for all requests to a Laravel application is the public/index.php
file. All requests are directed to this file by your web server (Apache / Nginx) configuration. The index.php
file doesn't contain much code. Rather, it is simply a starting point for loading the rest of the framework.
index.php
ファイルは、コンポーサーが生成したオートローダーの定義をロードします。それから、bootstrap/app.php
スクリプトから、Laravelアプリケーションのインスタンスを取得します。Laravel自身の最初のアクションは、アプリケーション/サービスコンテナのインスタンスを生成することです。The index.php
file loads the Composer generated autoloader definition, and then retrieves an instance of the Laravel application from bootstrap/app.php
script. The first action taken by Laravel itself is to create an instance of the application / service container[/docs/{{version}}/container].
HTTP/ConsoleカーネルHTTP / Console Kernels
次に、アプリケーションが起動された種類により、送信されてきたリクエストをHTTPカーネルか、コンソールカーネルのどちらかに送ります。これらのカーネルは、全リクエストフローの中心に位置し動作します。ここではapp/Http/Kernel.php
にある、HTTPカーネルに焦点を合わせます。Next, the incoming request is sent to either the HTTP kernel or the console kernel, depending on the type of request that is entering the application. These two kernels serve as the central location that all requests flow through. For now, let's just focus on the HTTP kernel, which is located in app/Http/Kernel.php
.
HTTPカーネルはIlluminate\Foundation\Http\Kernel
クラスを拡張しており、リクエストの実行前に処理されるbootstrappers(起動コード)の配列を定義しています。これらの起動コードはエラー処理、ログ設定、アプリケーション環境の決定、その他実際にリクエストが処理される前に行う必要のあるタスクです。The HTTP kernel extends the Illuminate\Foundation\Http\Kernel
class, which defines an array of bootstrappers
that will be run before the request is executed. These bootstrappers configure error handling, configure logging, detect the application environment, and perform other tasks that need to be done before the request is actually handled.
HTTPカーネルはさらに、アプリケーションによりリクエストが処理される前に通す必要のある、HTTPミドルウェアのリストも定義しています。これらのミドルウェアはHTTPセッションの読み書き、アプリケーションがメンテナンスモードであるかの決定、CSRFトークンの確認などを行います。The HTTP kernel also defines a list of HTTP middleware[/docs/{{version}}/middleware] that all requests must pass through before being handled by the application. These middleware handle reading and writing the HTTP session, determine if the application is in maintenance mode, verifying the CSRF token, and more.
HTTPカーネルのhandle
メソッドの使い方はとてもシンプルで、Request
を受け取り、Response
をリターンします。カーネルをアプリケーション全体を表す大きなブラックボックスだと考えてください。HTTPリクエストを流し込み、HTTPレスポンスが返ってきます。The method signature for the HTTP kernel's handle
method is quite simple: receive a Request
and return a Response
. Think of the Kernel as being a big black box that represents your entire application. Feed it HTTP requests and it will return HTTP responses.
サービスプロバイダーService Providers
カーネルの初期処理で重要な働きのひとつは、アプリケーションのサービスプロバイダーをロードすることです。アプリケーションの全サービスプロバイダーは、config/app.php
ファイルのproviders
配列で設定されています。最初に、全プロバイダーのregister
メソッドが呼び出され、その後に登録されている全プロバイダーのboot
メソッドが呼び出されます。One of the most important Kernel bootstrapping actions is loading the service providers for your application. All of the service providers for the application are configured in the config/app.php
configuration file's providers
array. First, the register
method will be called on all providers, then, once all providers have been registered, the boot
method will be called.
リクエストのディスパッチDispatch Request
アプリケーションの初期処理が済み、全サービスプロバイダーが登録されたら、ディスパッチするためにルーターへRequest
が手渡されます。ルーターはそのリクエストをルートかコントローラーにディスパッチし、その時にルートに指定されているミドルウェアも実行されます。Once the application has been bootstrapped and all service providers have been registered, the Request
will be handed off to the router for dispatching. The router will dispatch the request to a route or controller, as well as run any route specific middleware.
サービスプロバイダーの精査Focus On Service Providers
サービスプロバイダーは、Laravelアプリケーションの初期起動段階における、まさに鍵となるものです。アプリケーションインスタンスが作成され、サービスプロバイダーが登録され、初期起動を終えたアプリケーションでリクエストが処理されます。とてもシンプルです!Service providers are truly the key to bootstrapping a Laravel application. The application instance is created, the service providers are registered, and the request is handed to the bootstrapped application. It's really that simple!
Laravelアプリケーションがどう構築されているか、そしてサービスプロバーイダーによる初期起動の仕組みをしっかりと把握することは、とても重要です。もちろん、皆さんのアプリケーションのためのデフォルトサービスプロバイダーは、app/Providers
ディレクトリーに設置されています。Having a firm grasp of how a Laravel application is built and bootstrapped via service providers is very valuable. Of course, your application's default service providers are stored in the app/Providers
directory.
AppServiceProvider
は、デフォルトで全く空っぽです。このプロバイダーは、皆さんのアプリケーション自身の初期起動やサービスコンテナの結合を追加するために用意されています。もちろん、大きなアプリケーションであれば、まとまった初期起動種別ごとに分け、好きなだけのサービスプロバイダーを作成できます。By default, the AppServiceProvider
is fairly empty. This provider is a great place to add your application's own bootstrapping and service container bindings. Of course, for large applications, you may wish to create several service providers, each with a more granular type of bootstrapping.