LaravelはPHPのフレームワークとして広く使われています。
その人気の秘密の一つは、その整理されたディレクトリ構造にあります。
この記事では、各ディレクトリがどのような目的でどのように使用されるかを詳しく解説します。
Laravelのディレクトリ構造を理解することは、アプリケーションの効率的な開発と管理に不可欠です。
Laravelのディレクトリ構成
Laravelプロジェクトのルートディレクトリには、デフォルトで以下のディレクトリが存在しています。
$ ls -d */ app/ bootstrap/ config/ database/ public/ resources/ routes/ storage/ tests/ vendor/
app
アプリケーションの核となるコードを含んでいます。
アプリケーション内のほとんどのクラスはこのディレクトリ内にあります。
詳細は、後ほど説明します。
bootstrap
フレームワークを起動するapp.phpファイルが含まれています。
また、このディレクトリには、フレームワークが生成したパフォーマンス最適化用のファイルを含むキャッシュディレクトリがあります。
通常、このディレクトリ内のファイルを変更する必要はありません。
config
名前が示す通り、アプリケーションのすべての設定ファイルが含まれています。
これらのファイルをすべて読み、利用可能なオプションに慣れることが良いでしょう。
configディレクトリについては、次の記事内で説明しています。
database
データベースのマイグレーション、モデルファクトリ、シードが含まれています。
希望する場合、SQLiteデータベースを保持するためにもこのディレクトリを使用できます。
public
アプリケーションへのすべてのリクエストの入り口であるindex.phpファイルが含まれています。
このindex.phpにはオートローダーの設定がなされています。
このことにより、アプリケーション実行時に必要なクラス等を自動的に読み込むことができるようになっています。
Laravelにおけるリクエストライフサイクルについて、次の記事で解説しています。
また、このディレクトリには、画像やJavaScript、CSSといったフロントエンドのアセットも配置されます。
要するには、外部に見えるモノはこのディレクトリに配置するということです。
resources
Laravelのアーキテクチャは「MVC」でした。
「V」であるビューが、このディレクトリに配置されることになります。
ビューとともに、SassやJSなどの元となるアセットソースコードも置かれています。
これは、プロジェクト作成時点における状態になります。
ここに置かれているjsファイルやcssファイルは、そのままでは公開されません。
一旦、これらをコンパイル（コンパイル不要もある）する必要があるのです。
コンパイルすれば、自動的にpublic以下に設置されます。
整理すると次のようになります。
| public | 公開用の処理済みファイルが配置される場所 |
| resources | 処理されていないソースが置かれる場所 |
routes
アプリケーションの全てのルーティング設定が定義されています。
Laravelには初期状態で、web.php、api.php、console.phpなどのルートファイルが用意されています。
web.phpには、通常のWebアプリケーション向けのルートが定義されます。
web.phpに定義したルートは、セッションやCSRF保護といったWebアプリケーションで必要な各種機能が適用されます。
api.phpにはstatelessなAPIエンドポイント向けのルートを定義します。
こちらのルートではトークンベースの認証が適用され、セッションを利用しません。
console.phpではArtisanコマンドのルートが定義されます。
データベースマイグレーションやバッチ処理などをこのファイルで登録できます。
storage
Laravelアプリケーションの運用に必要な各種データをファイルとして保存するためのディレクトリです。
ディレクトリ構成と主なデータ種別は以下の通りです。
| app | アプリケーションで生成する任意のファイル |
| framework | Laravelフレームワーク自体が生成するキャッシュ等 |
| logs | アプリケーションのログファイル |
app以下にpublicディレクトリが存在しています。
ここには、プロフィールアバターなどのユーザー生成ファイルを保存することができます。
これらは、Web公開されるべきデータです。
そのためには、public/storageへシンボリックリンクを貼る必要があります。
Laravelでは、そのためのコマンドが用意されています。
php artisan storage:link
tests
Laravelアプリケーションの自動テストコードが含まれています。
ここには、PHPUnitを利用したユニットテストや機能テストのサンプルコードがすでに用意されています。
アプリケーションのテストコードをここに追加していきます。
その際、テストコードのクラス名はTestで終わるようにします。
テストは、ターミナルから「phpunit」コマンドや「php vendor/bin/phpunit」コマンドで実行できます。
また、テスト結果をより見やすく表示するために、「php artisan test」コマンドを使うことも可能です。
このディレクトリはアプリケーションのテストコードをまとめる場所となります。
そのため、アプリケーション開発時には頻繁に触ることになるでしょう。
vendor
Composerでインストールした依存パッケージが格納されている場所です。
Composerについては、次の記事で説明しています。
初期状態では、以下のパッケージが格納されています。
$ ls -d */ bin/ egulias/ hamcrest/ myclabs/ phpoption/ sebastian/ voku/ brick/ fakerphp/ laminas/ nesbot/ phpunit/ spatie/ webmozart/ composer/ filp/ laravel/ nette/ psr/ symfony/ dflydev/ fruitcake/ league/ nikic/ psy/ theseer/ doctrine/ graham-campbell/ mockery/ nunomaduro/ ralouphie/ tijsverkoyen/ dragonmantank/ guzzlehttp/ monolog/ phar-io/ ramsey/ vlucas/
appディレクトリ
アプリケーションの主要なコードは「app」ディレクトリに格納されることになります。
デフォルトでは、「App」名前空間として定義され、クラスのオートロードが行われます。
この辺の詳細は、ComposerのPSR-4規約をご覧ください。
「app」ディレクトリには、Console、Http、Providersなどのサブディレクトリがあります。
これらは、アプリケーションの中心的な処理を担います。
ConsoleはCLI経由のコマンドを、HttpはHTTPを介したリクエストをそれぞれ処理する部分です。
Artisanの「make」コマンドで新しいクラスを作ると、対応するディレクトリが自動でapp配下に作成されます。
例えば「php artisan make:job」を実行すると、app/Jobsディレクトリができます。
もちろん、手動でもクラスの作成は可能です。
ただ、クラスを作成するために「php artisan make」を利用することが推奨されています。
また、Laravelではよく使われるクラスのテンプレートが用意されています。
php artisan list make
上記のコマンドを実行すると、次のような表示を確認できます。
この中から、何個かピックアップして説明します。
make:channel
「Broadcasting」ディレクトリが作成されます。
このディレクトリには、アプリケーションのすべてのブロードキャストチャネルクラスが含まれています。
make:command
「Console」ディレクトリが作成されます。
このディレクトリには、アプリケーションのカスタムArtisanコマンドがすべて含まれています。
なお、「Console」ディレクトリは初期状態で存在しています。
make:event
「Events」ディレクトリが作成されます。
このディレクトリには、イベントクラスが含まれています。
イベントは、特定のアクションが発生したことをアプリケーションの他の部分に通知するために使用されます。
イベントを用いることにより、非常に柔軟で変更に対応しやすく、保守しやすい構造になります。
make:exception
「Exceptions」ディレクトリが作成されます。
このディレクトリには、アプリケーションの例外ハンドラが含まれています。
例外の記録やレンダリング方法をカスタマイズしたい場合は、
このディレクトリのHandlerクラスを変更する必要があります。
なお、「Exceptions」ディレクトリは初期状態で存在しています。
make:job
「Jobs」ディレクトリが作成されます。
このディレクトリには、アプリケーションのキュー可能なジョブが含まれています。
ジョブはアプリケーションによってキューに入れられるか、
現在のリクエストライフサイクル内で同期的に実行されます。
make:listener
「Listeners」ディレクトリが作成されます。
このディレクトリには、イベントを処理するクラスが含まれています。
イベントリスナーはイベントのインスタンスを受け取り、イベントが発生した際にロジックを実行します。
例えば、「UserRegistered」イベントは「SendWelcomeEmail」リスナーによって処理されるかもしれません。
make:mail
「Mail」ディレクトリが作成されます。
このディレクトリには、アプリケーションによって送信されるメールを表すクラスがすべて含まれています。
メールオブジェクトを使用すると、メールの構築ロジックを単一のシンプルなクラスにカプセル化できます。
そして、Mail::send メソッドを使ってメールを送信することができます。
make:model
「Models」ディレクトリが作成されます。
このディレクトリには、すべてのEloquentモデルクラスが含まれています。
Laravelに付属するEloquent ORMは、美しくシンプルなActiveRecord実装を提供します。
各データベーステーブルには、そのテーブルと対話するための「モデル」が対応しています。
モデルを使用すると、テーブル内のデータをクエリしたり、新しいレコードをテーブルに挿入したりすることができます。
なお、「Models」ディレクトリは初期状態で存在しています。
make:notification
「Notifications」ディレクトリが作成されます。
このディレクトリには、アプリケーションによって送信される「トランザクショナル」通知がすべて含まれています。
これには、アプリケーション内で発生するイベントに関するシンプルな通知などが含まれます。
Laravelの通知機能は、多様なドライバーを介して様々な通知を送信することを抽象化します。
- メール
- Slack
- SMS
- データベースに保存
make:policy
「Policies」ディレクトリが作成されます。
このディレクトリには、アプリケーションの認証ポリシークラスが含まれています。
ポリシーは、ユーザーがリソースに対して特定のアクションを実行できるかどうかを決定するために使用されます。
make:provider
「Providers」ディレクトリが作成されます。
このディレクトリには、アプリケーションのすべてのサービスプロバイダーが含まれています。
サービスプロバイダーは、アプリケーションの起動時に必要な設定やサービスを準備する役割を持ちます。
もう少し具体的に言うと、「サービスコンテナ」と呼ばれる場所にサービスを登録します。
つまり、アプリケーションにとって非常に重要な役割を果たすディレクトリと言えます。
実際、デフォルトでディレクトリが作成済みとなっています。
make:rule
「Rules」ディレクトリが作成されます。
このディレクトリには、アプリケーションのカスタム検証ルールオブジェクトが含まれています。
ルールは、複雑な検証ロジックをシンプルなオブジェクトにカプセル化するために使用されます。
