概要
LaravelはMVCアーキテクチャを基本としており、コードの整理と保守性を重視した設計となっている。
- アプリケーションのコア構造
- プロジェクトのルートディレクトリには、重要なディレクトリがいくつか配置されている。
- appディレクトリには、アプリケーションの中心となるコードが格納される。
- ここにはモデル、コントローラ、ミドルウェア等が含まれており、ビジネスロジックの大部分がこの中に実装される。
- ルーティングとリクエストの流れ
- 全てのリクエストは、public/index.phpファイルを通じて処理が開始される。
- その後、routesディレクトリ内で定義されたルーティング設定に基づいて、適切なコントローラへとリクエストが振り分けられる。
- 設定とリソース管理
- configディレクトリには各種設定ファイルが配置されており、データベース接続やメール設定等のアプリケーション全体の設定を管理する。
- また、resourcesディレクトリには、ビューテンプレート、言語ファイル、CSSやJavaScript等のアセットファイルが格納される。
- サービスプロバイダーとDI
- Laravelの特徴的な機能として、依存性注入 (DI) とサービスコンテナがある。
- app/Providersディレクトリ内のサービスプロバイダを通じて、様々なサービスの登録と初期化が行われる。
- これにより、疎結合なコードの実現とテスタビリティの向上が図られている。
- データベース操作
- databaseディレクトリには、マイグレーションやシーダが配置される。
- Eloquent ORMを使用することにより、データベース操作を直感的なオブジェクト指向的な方法で行うことができる。
- アーティザンコマンド
- コマンドラインインターフェース Artisan を通じて、様々な開発タスクを自動化できる。
- マイグレーションの実行、モデルやコントローラの作成等、開発効率を大きく向上させる機能が提供されている。
- セキュリティ機能
- フレームワークには、CSRFトークン、XSS対策、SQLインジェクション防止等、セキュリティ機能が標準で組み込まれている。
- app/Http/Middlewareディレクトリには、これらのセキュリティ関連の処理が実装されている。
このように、Laravelは必要な機能を論理的に配置して、開発者が効率的にアプリケーションを構築できるように設計されている。
フレームワークの各部分が明確な役割を持ち、かつ柔軟に拡張できる構造となっているのが特徴である。
ディレクトリ構成
ディレクトリ名 | 説明 |
---|---|
app | アプリケーションのプログラム部分が存在するディレクトリである。 アプリケーションの開発時には、必要なスクリプトファイルを追加する。 |
bootstrap | アプリケーションの起動時に実行される処理(laravelフレームワークの起動コード)が存在する。 |
config | 設定ファイルが存在するディレクトリである。 |
database | データベース関連のファイルが存在する。 MigrationファイルなどDB関連のファイル等が配置される。 |
public | 公開ディレクトリである。 CSS、JS等の外部に公開するファイルを配置する。 NginXおよびApache2のドキュメントルートの設定では、このディレクトリを指定する。 |
resources | プログラムが使用するリソース関連のファイル(例: ビューや言語変換用ファイル等)が存在するディレクトリである。 プログラムのテンプレートファイル等が存在する。 |
routes | ルーティング情報が保存されているディレクトリである。 アクセスするアドレスに割り当てられるプログラムの情報等が記載されている。 |
storage | アプリケーションのプログラムが保存するファイル等(例: ログファイル)を配置する。 |
tests | ユニットテスト関係のファイルが存在するディレクトリである。 テストコード等を配置する。 |
vendor | フレームワーク本体のプログラムが存在するディレクトリである。 Composerでインストールしたライブラリが保存されている。 |
appディレクトリ (コアディレクトリ)
appディレクトリは、アプリケーションの中核となるコードを格納する場所である。
アプリケーションの主要なビジネスロジックの多くがここに配置される。
以下に示すような構造により、コードの組織化と保守性が向上して、チーム開発においても明確な役割分担が可能となる。
また、テストパターンの記述にも考慮された設計となっている。
Consoleディレクトリ
Consoleディレクトリには、Artisanコマンドに関連するファイルが格納される。
Kernel.phpでは、定期実行するスケジュールタスクを定義でき、カスタムコマンドもここに配置する。
// app/Console/Commands/SendDailyReport.phpファイル
class SendDailyReport extends Command
{
protected $signature = 'report:daily';
protected $description = '日次レポートを送信する';
public function handle()
{
// レポート送信ロジック
}
}
Exceptionsディレクトリ
Exceptionsディレクトリには、アプリケーション固有の例外処理クラスを配置する。
Handler.phpで、例外処理の方法をカスタマイズできる。
Httpディレクトリ
最も頻繁に作業するディレクトリの1つである。
以下に示すような重要なコンポーネントが含まれる。
- Controllersディレクトリ
- リクエストの処理ロジックを担当
- Middlewareディレクトリ
- リクエスト / レスポンスの前後処理を実装
- Requests
- フォームリクエストのバリデーションルールを定義
- Resources
- APIレスポンスの整形を担当
- APIリソースを使用する場合にのみ必要である。
- 必要な場合は、以下に示すコマンドで生成する。
php artisan make:resource UserResource
Modelsディレクトリ
データベースとのやり取りを担当するEloquentモデルクラスが配置される。
リレーションシップやスコープ等のデータ操作ロジックを定義する。
// app/Models/User.phpファイル
class User extends Model
{
protected $fillable = ['name', 'email'];
public function posts()
{
return $this->hasMany(Post::class);
}
}
Providersディレクトリ
サービスプロバイダはアプリケーションの起動時に実行される重要なクラスである。
サービスの登録やイベントの設定等を行う。
Servicesディレクトリ
これは標準的なLaravelの構造には含まれないが、多くの開発者が作成する慣習的なディレクトリである。
ビジネスロジックを分離して、再利用可能なサービスクラスを配置する。
開発者が必要に応じて手動でディレクトリを作成する。
Eventsディレクトリ / Listenersディレクトリ
イベント駆動プログラミングをサポートするためのディレクトリである。
イベントクラスとそれを処理するリスナークラスを配置する。
これは標準的なLaravelの構造には含まれない。
イベント処理が必要な場合に、以下に示すコマンドで生成する。
# Eventsディレクトリの作成 php artisan make:event UserRegistered # Listenersディレクトリの作成 php artisan make:listener SendWelcomeEmail
Policiesディレクトリ
認可ロジックを定義する場所である。
特定のモデルに対する操作権限をきめ細かく制御できる。
これは標準的なLaravelの構造には含まれない。
認可ポリシーが必要な場合に、以下に示すコマンドで生成する。
php artisan make:policy UserPolicy
カスタマイズと拡張
Laravelでは、これらの基本構造に加えて、必要に応じて独自のディレクトリを作成することが推奨されている。
以下に例を示す。
- Repositories
- データアクセス層を分離する場合
- Actions
- 単一責任の原則に基づいたビジネスロジック
- DTOs
- データ転送オブジェクト
- Enums
- 列挙型クラス
resourcesディレクトリとpublicディレクトリの違い
resources ディレクトリ
ソースコードを配置する場所であり、コンパイル / バンドル前のファイルが置かれる。
Sass, TypeScript, モダンなJavaScript (ES6+) 等の開発用コードを配置する。
また、npmパッケージからインポートしたコードも含める。
これは、Vite / Webpackにより処理される前の状態である。
publicディレクトリ
Webブラウザから直接アクセス可能なファイルを配置する。
Webブラウザが解釈できる形式 (通常のCSS, ES5 JavaScript)
コンパイル / バンドル済みのファイルである。
(最適化・圧縮済みの本番向けのコード等)
(アセットのビルド後の出力先)
具体例
// resources/css/app.scss
@import 'variables';
.button {
@apply bg-blue-500;
&:hover {
@apply bg-blue-600;
}
}
// public/css/app.css (コンパイル後)
.button {
background-color: #3b82f6;
}
.button:hover {
background-color: #2563eb;
}
開発フロー
- resources 下で開発を行う。
- vite build / npm run build でコンパイル。
- 結果がpublicディレクトリに出力される。
- publicのファイルがWebサーバから配信される。
resourcesは開発向け、publicは本番配信向けという役割の違いがある。