Directory Structure
Introduction
デフォルトの Laravel アプリケーション構造は、大規模なアプリケーションと小規模なアプリケーションの両方に優れた出発点を提供することを目的としています。ただし、アプリケーションを自由に編成できます。 Laravel では、Composer がクラスを自動ロードできる限り、特定のクラスの配置場所にほとんど制限がありません。
The Root Directory
The App Directory
app ディレクトリには、アプリケーションのコア コードが含まれています。このディレクトリについては、後ほど詳しく説明します。ただし、アプリケーション内のほとんどすべてのクラスはこのディレクトリにあります。
The Bootstrap Directory
bootstrap ディレクトリには、フレームワークをブートストラップする app.php ファイルが含まれています。このディレクトリには、ルート キャッシュ ファイルやサービス キャッシュ ファイルなど、パフォーマンスを最適化するためにフレームワークで生成されたファイルが含まれる cache ディレクトリも格納されます。
The Config Directory
config ディレクトリには、名前が示すように、アプリケーションのすべての構成ファイルが含まれています。これらのファイルをすべて読んで、利用可能なすべてのオプションをよく理解することをお勧めします。
The Database Directory
database ディレクトリには、データベースの移行、モデル ファクトリ、およびシードが含まれています。必要に応じて、このディレクトリを使用して SQLite データベースを保持することもできます。
The Public Directory
public ディレクトリには、アプリケーションに入るすべてのリクエストのエントリ ポイントとなり、自動ロードを構成する index.php ファイルが含まれています。このディレクトリには、画像、JavaScript、CSS などのアセットも格納されます。
The Resources Directory
resources ディレクトリには、views と、CSS や JavaScript などの生の未コンパイル アセットが含まれています。
The Routes Directory
routes ディレクトリには、アプリケーションのすべてのルート定義が含まれています。デフォルトでは、Laravel には web.php と console.php という 2 つのルート ファイルが含まれています。
web.php ファイルには、Laravel がセッション状態、CSRF 保護、Cookie 暗号化を提供する web ミドルウェア グループに配置するルートが含まれています。アプリケーションがステートレスな RESTful API を提供していない場合、すべてのルートは web.php ファイルで定義される可能性が高くなります。
console.php ファイルでは、クロージャベースのコンソール コマンドをすべて定義できます。各クロージャはコマンド インスタンスにバインドされており、各コマンドの IO メソッドと対話する簡単なアプローチが可能になります。このファイルは HTTP ルートを定義しませんが、アプリケーションへのコンソール ベースのエントリ ポイント (ルート) を定義します。 console.php ファイルで schedule タスクを実行することもできます。
オプションで、install:api および install:broadcasting Artisan コマンドを使用して、API ルート (api.php) およびブロードキャスト チャネル (channels.php) の追加のルート ファイルをインストールできます。
api.php ファイルにはステートレスであることを目的としたルートが含まれているため、これらのルートを介してアプリケーションに入るリクエストは via tokens で認証されることを目的としており、セッション状態にはアクセスできません。
channels.php ファイルには、アプリケーションがサポートするすべての event broadcasting チャネルを登録できます。
The Storage Directory
storage ディレクトリには、ログ、コンパイルされた Blade テンプレート、ファイル ベースのセッション、ファイル キャッシュ、およびフレームワークによって生成されたその他のファイルが含まれています。このディレクトリは、app、framework、および logs ディレクトリに分離されています。 app ディレクトリは、アプリケーションによって生成されたファイルを保存するために使用できます。 framework ディレクトリは、フレームワークで生成されたファイルとキャッシュを保存するために使用されます。最後に、logs ディレクトリにはアプリケーションのログ ファイルが含まれます。
storage/app/public ディレクトリは、プロファイル アバターなど、パブリックにアクセスできる必要があるユーザー生成ファイルを保存するために使用できます。このディレクトリを指すシンボリック リンクを public/storage に作成する必要があります。 php artisan storage:link Artisan コマンドを使用してリンクを作成できます。
The Tests Directory
tests ディレクトリには自動テストが含まれています。 Pest または PHPUnit の単体テストと機能テストの例は、すぐに使用できるように提供されています。各テスト クラスには、Test という語の接尾辞を付ける必要があります。 /vendor/bin/pest または /vendor/bin/phpunit コマンドを使用してテストを実行できます。または、テスト結果をより詳細に美しく表現したい場合は、php artisan test Artisan コマンドを使用してテストを実行できます。
The Vendor Directory
vendor ディレクトリには、Composer 依存関係が含まれています。
The App Directory
アプリケーションの大部分は、app ディレクトリに格納されています。デフォルトでは、このディレクトリは App の下に名前空間が設定されており、PSR-4 autoloading standard を使用して Composer によって自動ロードされます。
デフォルトでは、app ディレクトリには、Http、Models、および Providers ディレクトリが含まれています。ただし、時間の経過とともに、make Artisan コマンドを使用してクラスを生成すると、アプリ ディレクトリ内に他のさまざまなディレクトリが生成されます。たとえば、app/Console ディレクトリは、make:command Artisan コマンドを実行してコマンド クラスを生成するまで存在しません。
Console ディレクトリと Http ディレクトリについては、以下のそれぞれのセクションで詳しく説明しますが、Console ディレクトリと Http ディレクトリは、アプリケーションのコアに API を提供するものであると考えてください。 HTTP プロトコルと CLI はどちらもアプリケーションと対話するメカニズムですが、実際にはアプリケーション ロジックは含まれません。言い換えれば、これらはアプリケーションにコマンドを発行する 2 つの方法です。 Console ディレクトリにはすべての Artisan コマンドが含まれ、Http ディレクトリにはコントローラ、ミドルウェア、リクエストが含まれます。
appディレクトリ内のクラスの多くは、Artisan がコマンドを使用して生成できます。使用可能なコマンドを確認するには、ターミナルでphp artisan list makeコマンドを実行します。
The Broadcasting Directory
Broadcasting ディレクトリには、アプリケーションのすべてのブロードキャスト チャネル クラスが含まれています。これらのクラスは、make:channel コマンドを使用して生成されます。このディレクトリはデフォルトでは存在しませんが、最初のチャネルを作成するときに作成されます。チャネルの詳細については、event broadcasting のドキュメントを参照してください。
The Console Directory
Console ディレクトリには、アプリケーションのカスタム Artisan コマンドがすべて含まれています。これらのコマンドは、make:command コマンドを使用して生成できます。
The Events Directory
このディレクトリはデフォルトでは存在しませんが、event:generate および make:event Artisan コマンドによって作成されます。 Events ディレクトリには event classes が含まれています。イベントを使用して、特定のアクションが発生したことをアプリケーションの他の部分に警告することができ、大幅な柔軟性と分離が実現します。
The Exceptions Directory
Exceptions ディレクトリには、アプリケーションのカスタム例外がすべて含まれています。これらの例外は、make:exception コマンドを使用して生成される場合があります。
The Http Directory
Http ディレクトリには、コントローラ、ミドルウェア、フォーム リクエストが含まれています。アプリケーションに入るリクエストを処理するロジックのほとんどは、このディレクトリに配置されます。
The Jobs Directory
このディレクトリはデフォルトでは存在しませんが、make:job Artisan コマンドを実行すると作成されます。 Jobs ディレクトリには、アプリケーションの queueable jobs が格納されます。ジョブはアプリケーションによってキューに入れられるか、現在のリクエストのライフサイクル内で同期的に実行されます。現在のリクエスト中に同期的に実行されるジョブは、command pattern の実装であるため、「コマンド」と呼ばれることがあります。
The Listeners Directory
このディレクトリはデフォルトでは存在しませんが、event:generate または make:listener Artisan コマンドを実行すると作成されます。 Listeners ディレクトリには、events を処理するクラスが含まれています。イベント リスナはイベント インスタンスを受信し、発生したイベントに応答してロジックを実行します。たとえば、UserRegistered イベントは、SendWelcomeEmail リスナによって処理される場合があります。
The Mail Directory
このディレクトリはデフォルトでは存在しませんが、make:mail Artisan コマンドを実行すると作成されます。 Mail ディレクトリには、アプリケーションによって送信されたすべての classes that represent emails が含まれています。メール オブジェクトを使用すると、電子メールを構築するすべてのロジックを、Mail::send メソッドを使用して送信できる単一の単純なクラスにカプセル化できます。
The Models Directory
Models ディレクトリには、Eloquent model classes のすべてが含まれています。 Laravel に含まれる Eloquent ORM は、データベースを操作するための美しくシンプルな ActiveRecord 実装を提供します。各データベース テーブルには、そのテーブルと対話するために使用される対応する「モデル」があります。モデルを使用すると、テーブル内のデータをクエリしたり、テーブルに新しいレコードを挿入したりできます。
The Notifications Directory
このディレクトリはデフォルトでは存在しませんが、make:notification Artisan コマンドを実行すると作成されます。 Notifications ディレクトリには、アプリケーション内で発生するイベントに関する単純な通知など、アプリケーションによって送信されるすべての「トランザクション」notifications が含まれています。 Laravel の通知機能は、電子メール、Slack、SMS などのさまざまなドライバを介した、またはデータベースに保存された通知の送信を抽象化します。
The Policies Directory
このディレクトリはデフォルトでは存在しませんが、make:policy Artisan コマンドを実行すると作成されます。 Policies ディレクトリには、アプリケーションの authorization policy classes が含まれています。ポリシーは、ユーザーがリソースに対して特定のアクションを実行できるかどうかを決定するために使用されます。
The Providers Directory
Providers ディレクトリには、アプリケーションのすべての service providers が含まれています。サービスプロバイダは、サービスコンテナーにサービスをバインドしたり、イベントを登録したり、その他のタスクを実行して、アプリケーションを受信リクエストに備えて準備したりすることによって、アプリケーションをブートストラップします。
新しい Laravel アプリケーションでは、このディレクトリにはすでに AppServiceProvider が含まれています。必要に応じて、このディレクトリに独自のプロバイダを自由に追加できます。
The Rules Directory
このディレクトリはデフォルトでは存在しませんが、make:rule Artisan コマンドを実行すると作成されます。 Rules ディレクトリには、アプリケーションのカスタム検証ルール オブジェクトが含まれています。ルールは、複雑な検証ロジックを単純なオブジェクトにカプセル化するために使用されます。詳細については、validation documentation をご覧ください。