ディレクトリ構成
- リクエストのライフサイクル
- 設定
- ディレクトリ構成
- フロントエンド
- サービスコンテナ
- ファサード
Laravelのデフォルトアプリケーション構造はアプリケーションの大小にかかわらず、素晴らしいスタートを切ってもらえることを意図しています。アプリケーションは皆さんのお好みに応じ、自由に体系立ててください。クラスがComposerによりオートローディングできるならば、Laravelはクラスをどこに配置するか強制することはまずありません。
だそうです。
以下のようなフォルダがプロジェクトの配下に存在します。
重要そうなディレクトリに★を付けてみました。
appディレクトリ★★★
アプリケーションのコアコードを配置します。アプリケーションのほとんど全部のクラスは、このディレクトリの中に設定されることを覚えておいてください。
だそうです。さらに以下のサブディレクトリがあります。
- Console
- Exceptions
- Http
- Models
- Providers
bootstrapディレクトリ
フレームワークを初期起動処理するapp.phpファイルを設置しています。このディレクトリには、ルートやサービスのキャッシュファイルなど、パフォーマンスを最適化するためのフレームワークで生成されたファイルを含むcacheディレクトリも含んでいます。通常、このディレクトリ内のファイルを変更する必要はありません。
だそうです。app.phpは以前ちらっとLaravelアプリの起動してるところを追っかけたときに見た気がしますが、とりあえず今後は放置ということで。
configディレクトリ★
名前が示す通り、アプリケーションの全設定ファイルを設置しています。全ファイルに目を通し、設定可能なオプションに慣れ親しんでおくのは良い考えでしょう。
色んな設定項目があるのでざっと見ておくとよさそうです。
databaseディレクトリ★★
データベースのマイグレーションとモデルファクトリ、初期値設定（シーディング）を配置しています。
開発当初のDB構築や開発中のテーブル追加、構造変更などで使いそうですね。
langディレクトリ★★
アプリケーションのすべての言語ファイルを格納します。
メッセージやラベルの多言語化などで使いそうですね。
デフォルトだと"en"というサブディレクトリにファイルが置いてあります。言語毎にサブディレクトリを作ってファイルを置くのでしょう。
publicディレクトリ★★★
アプリケーションへの全リクエストの入り口となり、オートローディングを設定するindex.phpファイルがあります。また、このディレクトリにはアセット（画像、JavaScript、CSSなど）を配置します。
ここが外部に公開されているフォルダでしたね。
resourcesディレクトリ★★★
ビューや、CSS、JavaScriptなどのコンパイルしていない、素のアセットを格納します。
？publicフォルダにもCSS, JavaSciptも置くようだけどresourcesと何が違うんだろう？
ビューはとても重要な要素ですね。以下に説明があります。
routesディレクトリ★★★
アプリケーションのすべてのルート定義を配置しています。デフォルトでルートファイルをいくつかLaravelは用意しています。web.php、api.php、console.php、channels.php。
Webアプリを開発するのであれば一番重要なのはweb.phpでしょうね。以下が説明になります。
web.phpファイルは、RouteServiceProviderがwebミドルウェアグループへ配置するルートを記述します。これにより、セッション状態、CSRF保護、およびクッキー暗号化が提供されます。アプリケーションがステートレスのRESTful
APIを提供しない場合は、すべてのルートがweb.phpファイルでほぼ定義されるでしょう。
storageディレクトリ
ログ、コンパイル済みBladeテンプレート、ファイルベースのセッション、ファイルキャッシュ、およびフレームワークが作成したその他のファイルが含まれます。
このディレクトリは、app、framework、logsディレクトリに分離されています。appディレクトリは、アプリケーションが作成したファイルを保存するために使用できます。frameworkディレクトリは、フレームワークが作成したファイルとキャッシュを保存するために使用します。最後に、logsディレクトリにはアプリケーションのログファイルを保存しています。
確かアプリがアップロードしたファイルがstorage\app\publicに保存されるんじゃなかったかな？
storage/app/publicディレクトリは、プロファイルアバターなど、一般にアクセス可能である必要のあるユーザー生成ファイルを保存するために使用します。このディレクトリを指すシンボリックリンクをpublic/storageに作成する必要があります。php artisan storage:link Artisanコマンドを使用してリンクを作成できます。
シンボリックリンクって思いっきりUNIX(Linux) 系なんだけどWindowsでもできるのかな？
プロジェクトファイルのpublicの下でコマンドを実行してみます。
エラーになりました。どうやらディレクトリが間違っているようです。
プロジェクトファイルの直下で実行すると成功しました。
C:\xampp\htdocs\example-app\public> php artisan storage:link
Could not open input file: artisan
C:\xampp\htdocs\example-app\public> cd ..
C:\xampp\htdocs\example-app> php artisan storage:link
INFO The [C:\xampp\htdocs\example-app\public\storage] link has been connected to [C:\xampp\htdocs\example-app\storage\app/public].
VSCodeのターミナルで見てみると
d----l という属性でstorageというディレクトリが出来ています。
$echo AAA > test.txt
とか適当にファイルを作ってみると
- public\storage\test.txt
- storage\app\public\test.txt
同じものができますね。
コマンドラインでDIRを実行すると<JUNCTION>という謎の表示とstrageの後に絶対パスで"C:\xampp\htdocs\example-app\storage\app\public"と表示されています。
ググるとすぐに見つかりました。へーWindowsにそんな機能があるんですね。
Windowsのジャンクション、ハードリンク、シンボリックリンクの違いについて解説
ジャンクション ＋ ハードリンク ＝ シンボリックリンク
だそうです。
Windowsのジャンクション(junction)とシンボリックリンク(symblic link)違い
ジャンクションの方が一般ユーザ権限で使えて簡単そうです。その代わりファイルへのリンクが出来ない、ネットワーク先へのリンクへが出来ないという制限がありますが、こういった用途であれば十分でしょう。
ログに関して
storage\logs\laravel.logにログがガンガン溜まっていきますね。
適当に消したいところです。良いサイトがあったので下にリンクを張っておきます。
Laravelのログを日別でローテーションさせる（ +自動削除 ）
config\logging.phpに設定項目があります。
'default' => env('LOG_CHANNEL', 'stack'),
'daily' => [
'driver' => 'daily',
'path' => storage_path('logs/laravel.log'),
'level' => env('LOG_LEVEL', 'debug'),
'days' => 14,
],
デフォルトではstackになっているのでこれをdailyに変えます。
またdailyの中に'days'という項目があります。これで保存期間の設定ができるようです。
testsディレクトリ
自動テストを設置します。たとえば、PHPUnitユニットテストと機能テストは、はじめから提供されています。各テストクラスには、Testという接尾辞を付ける必要があります。phpunitまたはphpvendor/bin/phpunitコマンドを使用してテストを実行できます。または、テスト結果をより詳細で美しい表現にしたい場合は、php artisan test Artisanコマンドを使用してテストを実行してください。
Unitテスト関連のファイルはここに置くようです。
vendorディレクトリ
アプリケーションで使うパッケージが保存されるディレクトリですね。
ディレクトリを見ると山ほどサブディレクトリとファイルがありますね。
サイズは57.5MB、けっこうありますね。
これってGitで管理したら大変だろうなと思ってぐぐったら、vendorディレクトリはGitで管理するなだそうです。
composer.jsonとcomposer.lockをGitで管理しておいて、composer installを実行するのがよさそうです。
composer update ではなく composer install を使った方がいいですね。
ざっくり言うと、前者は依存パッケージの最新バージョンをその場で探してインストールするのに対し、後者は composer.lock に記録されたバージョンをインストールします。こうすることで、開発環境と完全に一致したバージョンをインストールすることを保証します。
- composer.json：必要とするライブラリの種類と、必要なバージョンの条件が記載
- composer.lock：ライブラリをローカル環境でインストールしたときに、実際にインストールされたライブラリの種類とそれぞれのバージョンが記載
composer.lockがあれば実際にインストールされたライブラリとバージョンが分かるようです。
であればGitと同じものがローカルで再現できるようですね。
なので
- Gitを使わず、vendor以下も含めて丸ごとアーカイブしてコピーするか
- Gitを使って、composer.jsonとcomposer.lockを共有してcomposer installを実行して同じものを再現するか
の二択ですかね。
これでプロジェクトフォルダの直下にあるディレクリの構造がある程度わかりました。
