Laravel - Laravelの構造のソースを表示

== 概要 ==
LaravelはMVCアーキテクチャを基本としており、コードの整理と保守性を重視した設計となっている。<br>
<br>
* <u>アプリケーションのコア構造</u>
*: プロジェクトのルートディレクトリには、重要なディレクトリがいくつか配置されている。
*: appディレクトリには、アプリケーションの中心となるコードが格納される。
*: ここにはモデル、コントローラ、ミドルウェア等が含まれており、ビジネスロジックの大部分がこの中に実装される。
<br>
* <u>ルーティングとリクエストの流れ</u>
*: 全てのリクエストは、public/index.phpファイルを通じて処理が開始される。
*: その後、routesディレクトリ内で定義されたルーティング設定に基づいて、適切なコントローラへとリクエストが振り分けられる。
<br>
* <u>設定とリソース管理</u>
*: configディレクトリには各種設定ファイルが配置されており、データベース接続やメール設定等のアプリケーション全体の設定を管理する。
*: また、resourcesディレクトリには、ビューテンプレート、言語ファイル、CSSやJavaScript等のアセットファイルが格納される。
<br>
* <u>サービスプロバイダーとDI</u>
*: Laravelの特徴的な機能として、依存性注入 (DI) とサービスコンテナがある。
*: app/Providersディレクトリ内のサービスプロバイダを通じて、様々なサービスの登録と初期化が行われる。
*: これにより、疎結合なコードの実現とテスタビリティの向上が図られている。
<br>
* <u>データベース操作</u>
*: databaseディレクトリには、マイグレーションやシーダが配置される。
*: Eloquent ORMを使用することにより、データベース操作を直感的なオブジェクト指向的な方法で行うことができる。
<br>
* <u>アーティザンコマンド</u>
*: コマンドラインインターフェース Artisan を通じて、様々な開発タスクを自動化できる。
*: マイグレーションの実行、モデルやコントローラの作成等、開発効率を大きく向上させる機能が提供されている。
<br>
* <u>セキュリティ機能</u>
*: フレームワークには、CSRFトークン、XSS対策、SQLインジェクション防止等、セキュリティ機能が標準で組み込まれている。
*: app/Http/Middlewareディレクトリには、これらのセキュリティ関連の処理が実装されている。
<br>
このように、Laravelは必要な機能を論理的に配置して、開発者が効率的にアプリケーションを構築できるように設計されている。<br>
フレームワークの各部分が明確な役割を持ち、かつ柔軟に拡張できる構造となっているのが特徴である。<br>
<br><br>

== ディレクトリ構成 ==
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|-
! style="background-color:#66CCFF;" | ディレクトリ名 
! style="background-color:#66CCFF;" | 説明
|-
| app || アプリケーションのプログラム部分が存在するディレクトリである。<br>アプリケーションの開発時には、必要なスクリプトファイルを追加する。<br><br>多くのアプリケーションのクラスは、このディレクトリ内にて設定される。
|-
| bootstrap || アプリケーションの起動時に実行される処理(laravelフレームワークの起動コード)が存在する。<br>一般的に、このディレクトリ内のファイルを変更する必要はない。
|-
| config || 設定ファイルが存在するディレクトリである。
|-
| database || データベース関連のファイルが存在する。<br>MigrationファイルなどDB関連のファイル等が配置される。<br><br>このディレクトリは、SQLiteの設置場所としても利用できる。
|-
| public || 公開ディレクトリである。<br>画像、CSS、JS等の外部に公開するアセットファイルを配置する。<br><br>NginXおよびApache2のドキュメントルートの設定では、このディレクトリを指定する。
|-
| resources || プログラムが使用するリソース関連のファイル (例: ビュー、CSS、JS、言語変換用ファイル等) が存在するディレクトリである。<br>未コンパイルの素のアセットファイルを配置する。<br><br>プログラムのテンプレートファイル等が存在する。
|-
| routes || ルーティング情報が保存されているディレクトリである。<br>アクセスするアドレスに割り当てられるプログラムの情報等が記載されている。<br><br>初期状態では、web.php、api.php、console.php、channels.php等のルートファイルがある。<br>
* web.phpファイル
*: RouteServiceProviderがWebミドルウェアグループへ配置するルートを記述する。
*: これにより、セッション状態、CSRF保護、クッキー暗号化が提供される。
*: アプリケーションがステートレスのRESTful APIを提供しない場合は、全てのルートがweb.phpファイルでほぼ定義される。
* api.phpファイル
*: RouteServiceProviderがAPIミドルウェアグループへ配置するルートを記述する。
*: これらのルートはステートレスであることが意図されているため、
*: これらのルートを介してアプリケーションに入るリクエストは、トークンを介してで認証されることを意図しており、
*: セッション状態にアクセスできない。
* console.phpファイル
*: クロージャベースのコンソールコマンドを全て定義する場所を記述する。
*: 各クロージャはコマンドインスタンスと結合されるため、各コマンドのIOメソッドを操作する簡単なアプローチが可能である。
*: このファイルはHTTPルートを定義しないが、アプリケーションへのコンソールベースのエントリポイント (ルート) を定義している。
* channels.phpファイル
*: アプリケーションがサポートする全てのイベントブロードキャストチャンネルを登録できる場所を記述する。
|-
| storage || アプリケーションのプログラムが保存するファイル等 (例: ログファイル) を配置する。<br><br>コンパイル済みBladeテンプレート、ファイルベースのセッション、ファイルキャッシュ、フレームワークが作成したその他のファイルも含まれる。<br><br>このディレクトリは、app、framework、logsディレクトリに分離されている。<br>
* appディレクトリ
*: アプリケーションが作成したファイルを保存するために使用する。
* frameworkディレクトリ
*: フレームワークが作成したファイルとキャッシュを保存するために使用する。
* logsディレクトリ
*: アプリケーションのログファイルを保存している。
|-
| tests || ユニットテスト関係のファイルが存在するディレクトリである。<br>テストコード等を配置する。<br><br>例えば、PHPUnitユニットテストと機能テストは、最初から提供されている。<br>各テストクラスには、Testという接尾辞を付ける必要がある。<br><br>phpunitまたはphpvendor/bin/phpunitコマンドを使用してテストを実行できる。<br><br>また、テスト結果をより詳細に表示する場合は、<code>php artisan test Artisan</code>コマンドを使用してテストを実行する。
|-
| vendor || フレームワーク本体のプログラムが存在するディレクトリである。<br>Composerでインストールしたライブラリが保存されている。
|}
</center>
<br><br>

== appディレクトリ (コアディレクトリ) ==
appディレクトリは、アプリケーションの中核となるコードを格納する場所である。<br>
アプリケーションの主要なビジネスロジックの多くがここに配置される。<br>
<br>
以下に示すような構造により、コードの組織化と保守性が向上して、チーム開発においても明確な役割分担が可能となる。<br>
また、テストパターンの記述にも考慮された設計となっている。<br>
<br>
<u>※注意</u><br>
<u>以下に示すディレクトリは、<code>composer create-project laravel/laravel <プロジェクト名></code>コマンドでは自動生成されない。</u><br>
* Http/Resourcesディレクトリ
* Servicesディレクトリ
* Eventsディレクトリ
* Listenersディレクトリ
* Policiesディレクトリ
<br>
<u>開発者がディレクトリを作成する場合は、該当機能が必要になった時に作成することを推奨する。</u><br>
<u>また、可能な限り、Artisanコマンドを使用してディレクトリやファイルを生成することにより、Laravelの規約に従った適切な構造を維持できる。</u><br>
<br>
<u>頻繁に使用する構造がある場合は、カスタムのプロジェクトテンプレートを作成することも検討する。</u><br>
<br>
==== Consoleディレクトリ ====
Consoleディレクトリには、Artisanコマンドに関連するファイルが格納される。<br>
Kernel.phpでは、定期実行するスケジュールタスクを定義でき、カスタムコマンドもここに配置する。<br>
<br>
 <syntaxhighlight lang="php">
 // app/Console/Commands/SendDailyReport.phpファイル
 
 class SendDailyReport extends Command
 {
    protected $signature   = 'report:daily';
    protected $description = '日次レポートを送信する';
 
    public function handle()
    {
       // レポート送信ロジック
    }
 }
 </syntaxhighlight>
<br>
==== Exceptionsディレクトリ ====
Exceptionsディレクトリには、アプリケーション固有の例外処理クラスを配置する。<br>
Handler.phpで、例外処理の方法をカスタマイズできる。<br>
<br>
==== Httpディレクトリ ====
最も頻繁に作業するディレクトリの1つである。<br>
以下に示すような重要なコンポーネントが含まれる。<br>
<br>
* Controllersディレクトリ
*: リクエストの処理ロジックを担当
* Middlewareディレクトリ
*: リクエスト / レスポンスの前後処理を実装
* Requests
*: フォームリクエストのバリデーションルールを定義
* Resources
*: APIレスポンスの整形を担当
*: <br>
*: APIリソースを使用する場合にのみ必要である。
*: 必要な場合は、以下に示すコマンドで生成する。
*: <code>php artisan make:resource UserResource</code>
<br>
==== Modelsディレクトリ ====
データベースとのやり取りを担当するEloquentモデルクラスが配置される。<br>
リレーションシップやスコープ等のデータ操作ロジックを定義する。<br>
<br>
 <syntaxhighlight lang="php">
 // app/Models/User.phpファイル
 
 class User extends Model
 {
    protected $fillable = ['name', 'email'];
 
    public function posts()
    {
       return $this->hasMany(Post::class);
    }
 }
 </syntaxhighlight>
<br>
==== Providersディレクトリ ====
サービスプロバイダはアプリケーションの起動時に実行される重要なクラスである。<br>
サービスの登録やイベントの設定等を行う。<br>
<br>
==== Servicesディレクトリ ====
これは標準的なLaravelの構造には含まれないが、多くの開発者が作成する慣習的なディレクトリである。<br>
<br>
ビジネスロジックを分離して、再利用可能なサービスクラスを配置する。<br>
<br>
開発者が必要に応じて手動でディレクトリを作成する。<br>
<br>
==== Eventsディレクトリ / Listenersディレクトリ ====
イベント駆動プログラミングをサポートするためのディレクトリである。<br>
イベントクラスとそれを処理するリスナークラスを配置する。<br>
<br>
これは標準的なLaravelの構造には含まれない。<br>
イベント処理が必要な場合に、以下に示すコマンドで生成する。<br>
 # Eventsディレクトリの作成
 php artisan make:event UserRegistered
 
 # Listenersディレクトリの作成
 php artisan make:listener SendWelcomeEmail
<br>
==== Policiesディレクトリ ====
認可ロジックを定義する場所である。<br>
特定のモデルに対する操作権限をきめ細かく制御できる。<br>
<br>
これは標準的なLaravelの構造には含まれない。<br>
認可ポリシーが必要な場合に、以下に示すコマンドで生成する。<br>
 php artisan make:policy UserPolicy
<br>
==== カスタマイズと拡張 ====
Laravelでは、これらの基本構造に加えて、必要に応じて独自のディレクトリを作成することが推奨されている。<br>
<br>
以下に例を示す。<br>
* Repositories
*: データアクセス層を分離する場合
* Actions
*: 単一責任の原則に基づいたビジネスロジック
* DTOs
*: データ転送オブジェクト
* Enums
*: 列挙型クラス
<br><br>

== resourcesディレクトリ ==
==== resources/cssディレクトリ ====
このディレクトリは、アプリケーションで使用するCSSファイルを格納する場所である。<br>
コンパイル前のソースファイルを配置する場所という位置付けである。<br>
<br>
初期状態では、app.cssファイルのみが配置されている。<br>
<br>
また、SASSやLESS等のプリプロセッサのソースファイルもここに配置できる。<br>
<br>
 # ディレクトリ構造の例
 
 resources/
 └── css/
     ├── app.css
     ├── components/
     └── pages/
<br>
このディレクトリは、アプリケーションのフロントエンド開発における重要な役割を果たす。<br>
必要に応じて、サブディレクトリを作成して、コードを整理することもできる。<br>
<br>
<u>※補足</u><br>
* node_modulesのインストールが必要である。(npm install)
* ホットリロード開発が可能である。(npm run watch)
* SCSSやTypeScript等、必要な依存関係は別途インストールする必要がある。
* アセットのバージョニングやキャッシュバスティングも可能である。
<br>
==== resources/jsディレクトリ ====
このディレクトリは、アプリケーションで使用するJavaScriptファイルを格納する場所である。<br>
モジュールのインポートやコンポーネントの定義等を行う。<br>
<br>
VueやReact等のコンポーネントもこのディレクトリに配置する。<br>
また、TypeScriptを使用する場合のソースファイルもこのディレクトリに配置する。<br>
<br>
初期状態では、app.jsが配置されている。<br>
<br>
 # ディレクトリ構造の例
 
 resources/
 └── js/
     ├── app.js
     ├── components/
     ├── pages/
     └── bootstrap.js
<br>
<u>※補足</u><br>
* node_modulesのインストールが必要である。(npm install)
* ホットリロード開発が可能である。(npm run watch)
* SCSSやTypeScript等、必要な依存関係は別途インストールする必要がある。
* アセットのバージョニングやキャッシュバスティングも可能である。
<br>
==== コンパイルとバンドル ====
webpack.mix.jsファイル (Laravel Mix使用時)、あるいは、vite.config.jsファイル (Laravle 9以降) は、プロジェクトのルートディレクトリに自動的に配置される。<br>
<br>
 # Laravel Mix使用時 (Laravel 8以前)
 # Laravel新規プロジェクト作成時に自動で生成される
 # 手動で作成する場合は以下のコマンドで雛形を作成できる
 npm install laravel-mix --save-dev
 # その後、webpack.mix.jsを手動で作成する
 
 # Vite使用時 (Laravel 9以降)
 # Laravel新規プロジェクト作成時に自動で生成される
 # 手動でViteを追加する場合は以下のコマンドを実行
 composer require laravel/vite-plugin
 npm install --save-dev vite laravel-vite-plugin
<br>
これらの設定ファイルは、プロジェクトのアセットビルドプロセスを制御する重要なファイルであるため、バージョン管理システムにも含めることを推奨する。<br>
<br>
 <syntaxhighlight lang="js">
 // webpack.mix.jsでの設定例
 // Laravel Mixを使用する場合
 
 const mix = require('laravel-mix');
 
 mix.js('resources/js/app.js', 'public/js')
    .sass('resources/css/app.scss', 'public/css')
    .version();  // バージョニング
 </syntaxhighlight>
<br>
 <syntaxhighlight lang="js">
 // vite.config.jsでの設定例
 // Viteを使用する場合 (Laravel 9以降)
 
 import { defineConfig } from 'vite';
 import laravel from 'laravel-vite-plugin';
 import vue from '@vitejs/plugin-vue'; // Vue.jsを使用する場合
 
 export default defineConfig({
    plugins: [
       laravel({
          input: [
             'resources/css/app.css',
             'resources/js/app.js',
          ],
          refresh: true,
       }),
       vue(), // Vue.jsを使用する場合
    ],
 });
 </syntaxhighlight>
<br>
 # コンパイル
 
 # 開発環境
 npm run dev
 
 # 本番環境
 npm run prod
<br>
コンパイル後のファイルにおいて、CSSファイルは、public/cssディレクトリに出力される。<br>
JavaScriptファイルは、public/jsディレクトリに出力される。<br>
<br>
==== resources/viewsディレクトリ (Bladeテンプレートファイル) ====
Bladeテンプレートファイルは、resources/viewsディレクトリに配置されている。<br>
<br>
* メインのビューファイル
*: resources/viewsディレクトリにBladeテンプレートファイルを配置する。
*: ファイル名は、example.blade.phpのような形式とする。
*: <br>
* レイアウトファイル
*: resources/views/layoutsディレクトリに共通レイアウトを配置するのが一般的である。
*: 例: resources/views/layouts/app.blade.php
*: <br>
* パーシャル (部分) ビュー
*: resources/views/partialsディレクトリやresources/views/componentsディレクトリに配置するのが慣習的である。
*: ヘッダやフッタ等の再利用可能なコンポーネント
*: <br>
* メールテンプレート
*: resources/views/emailsディレクトリにメール用テンプレートを配置する。
<br>
また、ビューファイルの場所は、config/view.phpファイルで変更することも可能である。<br>
必要に応じて、サブディレクトリを作成して整理することもできる。<br>
<br>
===== デフォルトのwelcome.blade.phpの特徴 =====
* Laravelのウェルカムページとして機能
* Tailwind CSSを使用したスタイリング
* レスポンシブデザイン対応
* ダークモード対応
<br>
主なセクションを以下に示す。<br>
* ログイン / 登録リンク (認証系)
* Laravelロゴ
* ドキュメンテーションへのリンク
* Laracastsへのリンク
* Laravel Newsへのリンク
* エコシステムの紹介
<br>
===== 推奨設定 =====
以下に示すディレクトリは、必要に応じて作成する。<br>
初期状態ではwelcome.blade.phpのみが存在しており、アプリケーションの規模に合わせて構造化していくことが一般的である。<br>
<br>
* layoutsディレクトリを作成して、共通レイアウトを作成する。
* コンポーネントやパーシャルのためのディレクトリを作成する。
* ページ別のビューファイルを適切なディレクトリに整理する。
<br>
 resources/
 └── views/
     ├── components/  # 再利用可能なコンポーネント用
     ├── layouts/     # レイアウトテンプレート用
     ├── pages/       # 個別ページ用
     ├── partials/    # 部分的なビュー用
     ├── admin/       # 管理者専用の機能やビューを格納
     |                # 高度な権限が必要な操作のインターフェース
     |                # システム全体の管理や設定に関する画面
     |                # ユーザ管理、コンテンツ管理などの機能
     ├── user/        # 一般ユーザ向けの機能やビュー
     |                # プロフィール管理
     |                # 個人設定
     |                # ダッシュボード等、ユーザ固有の機能
     └── auth/        # 認証関連の全ての機能
                      # ログイン / 登録フォーム
                      # パスワードリセット
                      # メール確認
                      # 二要素認証 (必要な場合)
<br>
 # admin/ディレクトリの例
 
 resources/views/admin/
 ├── dashboard/           # 管理ダッシュボード関連
 │   ├── index.blade.php
 │   └── stats.blade.php
 ├── users/              # ユーザー管理関連
 │   ├── index.blade.php
 │   ├── create.blade.php
 │   ├── edit.blade.php
 │   └── show.blade.php
 ├── settings/           # 管理設定関連
 │   ├── general.blade.php
 │   └── security.blade.php
 └── layouts/            # 管理画面専用レイアウト
     └── admin.blade.php
<br>
 # user/ディレクトリの例
 
 resources/views/user/
 ├── profile/             # プロフィール関連
 │   ├── show.blade.php
 │   └── edit.blade.php
 ├── dashboard/           # ユーザダッシュボード
 │   └── index.blade.php
 ├── settings/            # ユーザ設定
 │   ├── account.blade.php
 │   └── notifications.blade.php
 └── layouts/             # ユーザ画面用レイアウト
     └── user.blade.php
<br>
 # auth/ディレクトリの例 (Laravel UI や Breezeを使用した場合)
 
 resources/views/auth/
 ├── login.blade.php        # ログインフォーム
 ├── register.blade.php     # 登録フォーム
 ├── verify.blade.php       # メール確認
 ├── passwords/             # パスワード関連
 │   ├── email.blade.php      # パスワードリセットメール送信
 │   ├── reset.blade.php      # パスワードリセットフォーム
 │   └── confirm.blade.php    # パスワード確認
 └── layouts/               # 認証用レイアウト
     └── auth.blade.php
<br>
Laravelのディレクトリ構造は、プロジェクトの要件に応じて柔軟に調整することができる。<br>
論理的で管理しやすい構造を維持することが重要である。<br>
* 一貫した命名規則
*: 複数形でリソースを表現 (users, posts)
*: 動作を表す単語で操作を表現 (create, edit, show)
* モジュール化
*: 各セクション専用のレイアウトファイル
*: 再利用可能なコンポーネントの活用
*: パーシャルビューの適切な使用
* アクセス制御
*: ミドルウェアと組み合わせて適切なアクセス制御を実装
*: 権限に基づいたビューの表示制御
<br><br>

== resourcesディレクトリとpublicディレクトリの違い ==
==== resources ディレクトリ ====
ソースコードを配置する場所であり、コンパイル / バンドル前のファイルが置かれる。<br>
Sass, TypeScript, モダンなJavaScript (ES6+) 等の開発用コードを配置する。<br>
<br>
また、npmパッケージからインポートしたコードも含める。<br>
<br>
これは、Vite / Webpackにより処理される前の状態である。<br>
<br>
==== publicディレクトリ ====
Webブラウザから直接アクセス可能なファイルを配置する。<br>
Webブラウザが解釈できる形式 (通常のCSS, ES5 JavaScript)<br>
<br>
コンパイル / バンドル済みのファイルである。<br>
(最適化・圧縮済みの本番向けのコード等)<br>
(アセットのビルド後の出力先)<br>
<br>
==== 具体例 ====
 <syntaxhighlight lang="scss">
 // resources/css/app.scss
 
 @import 'variables';
 .button {
   @apply bg-blue-500;
   &:hover {
     @apply bg-blue-600;
   }
 }
 </syntaxhighlight>
<br>
 <syntaxhighlight lang="scss">
 // public/css/app.css (コンパイル後)
 
 .button {
   background-color: #3b82f6;
 }
 
 .button:hover {
   background-color: #2563eb;
 }
 </syntaxhighlight>
<br>
==== 開発フロー ====
# resources 下で開発を行う。
# vite build / npm run build でコンパイル。
# 結果がpublicディレクトリに出力される。
# publicのファイルがWebサーバから配信される。
<br>
resourcesは開発向け、publicは本番配信向けという役割の違いがある。<br>
<br><br>


{{#seo:
|title={{PAGENAME}} : Exploring Electronics and SUSE Linux | MochiuWiki
|keywords=MochiuWiki,Mochiu,Wiki,Mochiu Wiki,Electric Circuit,Electric,pcb,Mathematics,AVR,TI,STMicro,AVR,ATmega,MSP430,STM,Arduino,Xilinx,FPGA,Verilog,HDL,PinePhone,Pine Phone,Raspberry,Raspberry Pi,C,C++,C#,Qt,Qml,MFC,Shell,Bash,Zsh,Fish,SUSE,SLE,Suse Enterprise,Suse Linux,openSUSE,open SUSE,Leap,Linux,uCLnux,Podman,電気回路,電子回路,基板,プリント基板
|description={{PAGENAME}} - 電子回路とSUSE Linuxに関する情報 | This page is {{PAGENAME}} in our wiki about electronic circuits and SUSE Linux
|image=/resources/assets/MochiuLogo_Single_Blue.png
}}

__FORCETOC__
[[カテゴリ:Web]]