[Laravel5]チュートリアル書籍でLaravelにざっと触れてみる１〜モデルの作成まで〜

新しい言語なりフレームワークを触る時は、まずチュートリアルをなぞって全体像を把握しようと努めます。

私の場合、全体像を把握しないままドキュメントを読んでも、ほとんど理解できず眠くなってしまうので。

公式のチュートリアルは5.2で止まっているようなので、今回はAmazon Kindle書籍として発行されている「 PHPはじめてのフレームワーク Laravel 5.5対応ステップ１ [プリント・レプリカ] Kindle版」（以下このシリーズの記事では参考書と表記します）で、ざっと流して全体像を把握してみたいと思います。

こちらの書籍はKindle Unlimitedで読み放題だったのと、続編がステップ４まで出ていたので公式よりも情報量が豊富そうだったから選びました。著者の方とは何の関係もございません。

本家5.2のチュートリアルはこちら
基本のタスクリスト 5.2 Laravel
中級者向けタスクリスト 5.2 Laravel

開発環境

開発環境はVagrantで、

CentOS release 6.9 (Final)
Server version: Apache/2.2.15 (Unix)
PHP 7.1.10 (cli) (built: Sep 27 2017 08:42:15) ( NTS )

sudo yum -y install --enablerepo=remi,remi-php71 php php-devel php-mbstring php-mcrypt php-mysql php-pear php-gd php-xml php-tidy php-soap php-xmlrpc php-ftp php-intl php-pecl-zip php-pecl-xdebug

Composer version 1.5.2 2017-09-11 16:59:25

echo &quot;&gt; composerをインストール&quot;
sudo curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer
echo &quot;&gt; composer高速化のためcomposerのリポジトリをhttps://packagist.jpに変更&quot;
echo &quot;&gt; hirak/prestissimoをインストール&quot;
composer config -g repos.packagist composer https://packagist.jp &amp;&amp; composer global require hirak/prestissimohirak/prestissimo

上記の構成です。
データベースはクローズドの社内サーバで運用しているMySQL5.5.45を使用します。

私はこのようなスタイルに慣れているので自前の仮想サーバを用意しますが、参考書ではCloud9を利用する方法を解説していますので、環境構築になれていない方でも大丈夫でしょう。

Laravelプロジェクトの作成

仮想環境の/var/www/html/publicがドキュメントルートになるようにLaravelのプロジェクトを作成します。バージョンは指定せず最新のものを利用します。（執筆時5.5.19）

cd /var/www/
composer create-project laravel/laravel html

WEBサーバのドキュメントルートを/var/www/html/publicにして、ブラウザからアクセスした時に以下の画面が出ればインストール完了です。

#.envファイルの編集

.envファイルを編集してLaravelアプリケーションの環境設定を行います。前述のコマンドでComposerからインストールしている場合はアプリケーションのルートディレクトリに存在します。*1

参考：設定 5.5 Laravel

今回はデータベースの設定だけすればいいので以下の部分を埋めます。

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret

参考書にはDB_PASSWORDを空にすると書かれていますが、DBユーザにパスワードを設定している場合は当然パスワードを記述する必要があります。

マイグレーションファイルとDBテーブルの作成

Laravelではマイグレーションファイルというphpファイルでデータベーステーブルを管理します。Laravelの基本的なDB構築は以下のような手順を想定しているようです。

artisan make:migrationでマイグレーションファイルを作成
作成されたマイグレーションファイルを編集してテーブルを定義
artisan migrateでマイグレーションファイルに定義したテーブルを作成する

テーブルに更新があればマイグレーションファイルを編集しマイグレーションを実行するという流れのようですが、DBを扱い慣れているエンジニアにとっては面倒な手順に感じます。CakePHPの場合、DBテーブルありきでモデルやコントローラ、ビューを作るフローだったので都合がよかったのですが、Laravelの場合は逆になっています。

複数人のシステム開発でメンバーそれぞれが開発環境を持ちDBも編集するような場合はマイグレーションは便利なのかもしれませんが、私の経験してきた開発現場ではDBの設計や管理を複数人で行うことはないのでマイグレーションを必要とするケースがあまりないんですよね。*2

ただ、そのことを不満に感じているような声は少なそうなので、現場では問題にならないのかもしれませんね。マイグレーションを使わなくてもDBは扱えるようですし、既存のテーブルからマイグレーションファイルを生成する方法もあるようなので、使いながら答えを見つけていきたいと思います。

booksテーブルを作成

マイグレーションを使わないとは言いつつ、どのように動くのか知った上で判断したいので参考書通りにすすめます。
Laravelを設置したディレクトリ*3 で以下のコマンドを実行します。

php artisan make:migration create_books_table --create=books

すると./database/migrations/に[年月日時]_create_books_table.phpというマイグレーションファイルが追加されます。
追加されたマイグレーションファイルのup()メソッドを以下のように書き換えます。

public function up()
{
    Schema::create(&#039;books&#039;, function (Blueprint $table) {
        $table-&gt;increments(&#039;id&#039;);
        $table-&gt;string(&#039;item_name&#039;);
        $table-&gt;integer(&#039;item_number&#039;);
        $table-&gt;integer(&#039;item_amount&#039;);
        $table-&gt;dateTime(&#039;published&#039;);
        $table-&gt;timestamps();
    });
}

Schema::defaultStringLengthを変更する

Laravel5.4からDBのcharsetがutf8mb4変更になったようですが、Laravelのartisan migrationではstringをvarchar(255)で作成しようとするため、5.7.7以前のMySQLでvarchar(255)にindexを貼ろうとするとエラーが出るようです。（参考）

Laravelはcreate-projectした段階でCreateUsersTableのマイグレーションが含まれていて、emailにユニークキーインデックスが貼られているために、下記のようなエラーが出ます。

Before

参考書に従って/app/Providers/AppServiceProvider.phpを編集します。
use演算子でIlluminate\Support\Facades\Schemaを追加。bootメソッドにSchema::defaultStringLength(191);を追加します。

defaultStringLengthを修正後にphp artisan migrateを実行して、以下のような結果になれば成功です。

After

更に詳しく知りたい方はこちらのサイトが参考になります。
MySQLのインデックスサイズに767byteまでしかつかえない問題と対策 – ハマログ

Bookモデルを作成

php artisan make:model Book

上記のコマンドで/app/Book.phpが作成されます。
CakePHPと同じようにモデル名を複数形のスネークケースにした名前Book→booksがテーブル名と決まっているため、規約に則るかぎりは何も指定しなくてもbooksテーブルが扱えるようです。テーブル名とモデル名を切り離したい時は、モデルのプロパティにprotected $table = 'テーブル名';と定義することもできるようですが、私のCakePHPの経験では必要になったことはありませんので、規約に従ったほうがいいでしょう。

CakePHPならDBテーブルを元にモデルを作成してくれるので、フィールド情報を読み込んでバリデーションを設定できたり、他のテーブルのIDを持っていたらアソシエーションを貼りますか？と聞いてくれたりと親切だったのですが、Laravelはどうなんでしょう。
せっかく長年使い続けてきたCakePHPから移行するので、この辺のところを深掘りして今までよりも便利で高速な開発ができるようになりたいものです。

私の環境だと/var/www/html/.env [↩]
当然ながらDBはシステムのキモであり、複数人が自由に触れる状況はあまり考えられないと思います。大きなシステムの場合はセクションごとに設計担当者が別れるということはあってもいいと思いますが、思想や設計にブレがないように管理する人（またはチーム）がいるべきなので、それ以外の人がデータベースの構造に手を入れない方が安全であると考えます。DBを管理する人がいるなら、あえてLaravelのマイグレーションで各メンバーの開発環境にDBを構築するのは無駄が多いので社内の開発用サーバでDBを運用する方が簡単で便利な点が多いので弊社ではそのように運用しています。ちなみにオープンソースやソースを配布するような場合には本来の意味でマイグレーションは役立つと思います。 [↩]
私なら/var/www/html/ [↩]