既存のDBからfactoryファイルを自動作成
既存のDBからmigrationファイルを自動作成によって、テストのために空のDBテーブルの作成が可能となりました。今度は、そこへテストデータを作成するためにfactoryが必要となります。これも自動作成しましょう。
既存のDBからmigrationファイルを自動作成によって、テストのために空のDBテーブルの作成が可能となりました。今度は、そこへテストデータを作成するためにfactoryが必要となります。これも自動作成しましょう。
またまたLaravelの更新の時期がやってきました。と言っても、またしても遅れての私のキャッチアップです。Laravel 6.xのバージョンは、Laravel 5.5と同様にLTSの長期サポートまでなので、バグの修正は、9/3/2021まで、セキュリティの修正は、9/3/2022までとあるので、できるならアップグレードしたいです。また、6.xのバージョンは、新サービスのサーバーレス対応のVaporでは必須ゆえに、Laravelを実行するサーバーのスケールアップに興味があるなら、なおさら頑張ってアップグレードする必要あります。
私が現在管理するプロジェクトのほとんどは、Laravelのフレームワーク採用以前から存在したphpのプロジェクトです。嬉しいことにお客様から移行の機会を与えられて、ほとんどLaravelに書き換えることができました。しかし、それらのプロジェクトのDBの管理には、Laravelのmigrationを使用していません。私が開発したオンラインのツールが生成するSQLファイルでDBの変更を行っています。最近になって、プロジェクトのデータベーステストを行う必要が出て、migrationのファイルを用意しなければなくなりました。
Laravelを使用した開発においてこれは心掛けたい、というガイドがあったらいいなあと、思っていたら、ありました。 オリジナルは英語ですが、日本語訳あります。 https://github.com/alexeymezenin/laravel-best-practices/blob/master/japanese.md 単一責任の原則 ファットモデル, スキニーコントローラ バリデーション ビジネスロジックはサービスクラスの中に書く 繰り返し書かない (DRY) クエリビルダや生のSQLクエリよりもEloquentを優先して使い、配列よりもコレクションを優先する マスアサインメント Bladeテンプレート内でクエリを実行しない。Eager Lodingを使う(N + 1問題) コメントを書く。ただしコメントよりも説明的なメソッド名と変数名を付けるほうが良い JSとCSSをBladeテンプレートの中に入れない、PHPクラスの中にHTMLを入れない コード内の文字列の代わりにconfigファイルとlanguageのファイル、定数を使う コミュニティに受け入れられた標準のLaravelツールを使う…