Laravel + Docker 環境のディレクトリ構成とファイルの概要
目次
- .docker
- app
- bootstrap
- config
- database
- node_modules
- public
-
resource
- ∟ js
- ∟ Views
- routes
- storage
- tests
- vendor
- その他主要ファイル
- 環境構築のポイント
.dockerディレクトリ
- ローカル環境専用
- 各種サーバー構成を記述
-
docker-compose.yamlが起点となり.docker内の設定が呼び出される - WebとAppの分離は必須ではなく、PHPでは通常WebとAppが一体化
appディレクトリ
- Laravelの主要な処理が動作する場所
-
Httpディレクトリにはアプリケーションロジックの中心である、Controller、Model、Middleware、Requestなどが存在する
Controllerディレクトリ
- ビューからルートを通じてコントローラーが動作。
-
リソースコントローラーの基本メソッド：
-
index：一覧表示 -
create：新規作成ページを表示 -
store：データベースに新規登録 -
show：詳細表示 -
edit：編集ページを表示 -
update：データを更新 -
destroy：削除
-
createとstoreの違い
create：新規作成ページを表示するだけ
store：新規作成ページを表示し、データベースに値を登録するまで（確認ボタンを押した時など）
showとeditの違い
edit：詳細ページを表示するだけ
update：詳細を表示して更新
Middlewareディレクトリ
HTTPリクエストとレスポンスを処理するためのフィルタリング層を提供
-
リクエストの前処理
ex)認証チェックや入力データのサニタイズ、アクセス制御（IP制限やロールベースの権限確認）を行う。 -
レスポンスの後処理
レスポンスデータの加工や、ヘッダーの追加、ログ記録などを行います。 -
リクエストを途中で拒否可能
条件に応じてリクエストを止めたり、特定のレスポンスを返すことができます。
Requestsディレクトリ
リクエストデータのバリデーションや認可処理をカプセル化して提供します。
バリデーション処理を記述。
使用例：
- リクエストデータのバリデーション
- リクエストの認可（Authorization）
Modelディレクトリ
- Eloquentを仕様して直感的なデータベースの操作が可能
- リレーション・スコープ・アクセサなど、柔軟な機能で開発を効率化
- コードが簡潔で、データ処理のロジックをモデル内にカプセル化できるため、保守性が高い
リレーション
モデル間のリレーション（関連付け）を定義
1対1
public function user()
{
return $this->hasOne(User::class);
}
1対多
public function comments()
{
return $this->hasMany(Comment::class);
}
多対多
public function tags()
{
return $this->belongsToMany(Tag::class);
}
providersディレクトリ
- システムの初期化処理。
- サーバー起動時に毎回実行。
- ミドルウェアの上位互換的な役割。
bootstrapディレクトリ
- 初期起動時の処理。
- キャッシュファイルの保存先。
-
.envではなくキャッシュファイルを参照することでサーバーパフォーマンスを向上。
configディレクトリ
- 設定値の一元管理。
- プロジェクト全体で不変の定数を記述。
Factoryディレクトリ
- Eloquentモデルに関連するテストデータやダミーデータを簡単に作成する。
- Factoryは普通Seederと一緒に使われる
- 命名規則：通常、対象モデルの名前にFactoryを付けた形式。
Factoryは、おもちゃを作る工場みたいなもの。工場には型（テンプレート）があって、同じ型を使って、たくさんのおもちゃを一気に作るイメージ。
Migrationディレクトリ
- テーブルの作成、カラムの追加を行う
- 履歴の管理ができるため使われる（過去にどんなテーブル、カラムを作ったかなど）
- 環境を跨いだときにみんなが同じ状態のテーブルを触れる
Seedersディレクトリ
- 仮データの作成
- 実際の環境のtestingテーブルに入る
- 基本Factoryと一緒に使われる
- 基本ローカルのみで使用される
FactoryとSeederの違い
| 項目 | Factory | Seeder |
|---|---|---|
| 主な用途 | モデルインスタンスのダミーデータ生成。主にテストやシーディングで利用される | データベースへの初期データ投入。主に開発環境や本番環境での初期設定データ作成。 |
| データの保存 | DBに保存するかどうかは使用者が選択できる（make or create）。 | DBにデータを直接保存する。 |
| 定義の場所 | database/factories ディレクトリ。モデルごとにファクトリークラスを定義。 | database/seeders ディレクトリ。必要に応じてSeederクラスを作成。 |
| 主な構成内容 | モデルに関連付けられたランダムなデータ生成テンプレート。 | データの生成と保存ロジック。ファクトリーや手動で作成したデータを含む。 |
| 主な用途の場面 | テスト、開発時の大量のモックデータ作成。 | 開発環境や本番環境での初期データ投入。 |
| 使用する場面 | テストコード、Seeder内、開発環境での利用。 | php artisan db:seed コマンドでの実行。 |
node_modulesディレクトリ
- npm(Node.jsのパッケージ管理ツール)やyarnによってインストールされた依存パッケージが保存されるフォルダ
- プロジェクト内で使用するサードパーティのモジュール（ライブラリ）をローカルに保存し、それらをコード内で利用可能にする
publicディレクトリ
- 公開可能なファイルを配置。
-
.htaccess：Webサーバーの制御（例：メンテナンス画面の設定） - メンテナンス画面を出すときにここに指定する
resourceディレクトリ
-
フロントエンド関連のファイルを管理
-
js配下にComponents・Layouts・Pages・typesディレクトリを配置。 -
app.ts：フロントエンドのエントリポイント。
-
Componerntsディレクトリ
再利用可能なVueコンポーネント（例：ボタン、ドロップダウン）。
Layoutsディレクトリ
固定部分（例：ヘッダー）。
Pagesディレクトリ
pagesのディレクトリは以下のファイル名がルート名になることが多い
ページ単位かデータ単位でのやり取りを行う
Viewsディレクトリ
- 画面遷移が行われるかどうか
- 旧来の動き方
- SPAじゃなくても良い固定ページを作るときに使う 例）メールの定型分(blade)
SPA（シングルページアプリケーション）：ページを遷移してもリロードが起こらない
routesディレクトリ
- フロントとバックエンドの接続。
storageディレクトリ
- 画像、CSV、ログファイルなどを配置。
- 容量が大きいファイルも保存可能。
testsディレクトリ
-
テストコードを管理。
- FeatureTest：機能単位のテスト。
- UnitTest：メソッド単位の細かいテスト。
vendorディレクトリ
- Composer（PHPのパッケージマネージャー）で管理されるライブラリ。
その他主要ファイル
-
.env：環境変数ファイル（開発・ステージング・本番環境で異なる設定を管理）。 -
.env.example：.envの雛形。 -
artisan：Laravelのコマンドラインツール。 -
composer.json：PHPパッケージの設定。 -
docker-compose.yaml：Docker構成を定義。 -
phpunit.xml：テスト設定。 -
tsconfig.json：TypeScriptのコンパイル設定。 -
vite.config.js：ビルドツールの設定。