use ~/Auth; 　追加

$hoge = Auth::user();

はじめに

このブログは2部構成です。
前編では、プロジェクト、コントローラー、モデル、テーブルの作成、サイトへのアクセスを
後編では、CRUDの作り方、データの１連の流れを紹介していきます。

狙い

mysqlのバージョンをあげてからmysqlを使えなくなった。
(migrationコマンドは通るが、データの登録が通らないのでsqliteを使うことでデータの登録、更新ができた。)

バージョン(2019年4月3日時点)

$ php -v
PHP 7.3.3 (cli) (built: Mar  8 2019 16:40:07) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.3, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.3, Copyright (c) 1999-2018, by Zend Technologies

開発環境

vagrantを使う。

vagrantを使用した開発環境の構築についてはここでは紹介しない。

仮想環境にアクセスする

$vagrant up

でvagrantを立ち上げる。

$vagrant ssh

で、vagrantにssh接続する

vagrant@homestead:~$ cd /vagrant/

することでホームディレクトリに移動する

プロジェクトを作成する

vagrant@homestead:/vagrant$ composer create-project laravel/laravel example

プロジェクトに移動する

vagrant@homestead:/vagrant$ cd example/
vagrant@homestead:/vagrant/example$ 

コントローラーとモデルを作成する

上：コントローラー、下：モデル(migrationファイルも作成される)

php artisan make:controller ExampleController -r
php artisan make:model Example -m

.envを編集する

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

を

DB_CONNECTION=sqlite

にした後でsqliteを使うために以下コマンドをうちます。

$touch database/database.sqlite

ここまで来たらもう少しです。頑張ってください。

migrationファイルの作成

database/migration/20YY_MM_DD_HHMMSS_create_examples_table.php

ファイルを編集していく

public function up()
{
    Schema::create('examples', function (Blueprint $table) {
        $table->bigIncrements('id');
        $table->timestamps();
    });
}

public function up()
{
    Schema::create('examples', function (Blueprint $table) {
        $table->bigIncrements('id');
        $table->string('title');//追加
        $table->text('content');//追加
        $table->timestamps();
    });
}

ちなみに、create_user,create_passwordテーブルは今回使用しないので、削除しても構いません。

できたら、migrateコマンドを打ってテーブルを作成します。

$php artisan migrate
Migrating: 2019_04_03_084022_create_examples_table
Migrated:  2019_04_03_084022_create_examples_table

が出てきたら成功です。

サイトを見てみよう

もう一つterminalを開いて自分が作成したフォルダまで移動して以下のコマンドを打つ。

$php artisa serve
Laravel development server started: <http://127.0.0.1:8000>

と出てくるので、ブラウザでhttp://localhost:8000にアクセスする。

このページが見れたらOK！

(後編へ続く)

フレームワークのキモ、サービスコンテナの仕組みを学ぶ

フレームワークは様々な機能を持つ数多くのクラスで構成されている。
これらのクラスのインスタンスを管理するのがサービスコンテナです。

サービスコンテナとは

複数のクラスが同じ機能を利用する際、利用するクラスに応じてインスタンスが生成される。これはコードの複雑化に繋がり効率、処理漏れの部分でも不具合を招く可能性が高い。これに対し、インスタンス管理の役割を担っているのがサービスコンテナです。
サービスコンテナに対してインスタンスを「要求」するだけです。
また、クラス内で必要となる機能クラスのインスタンスを、コンストラクタやメソッドの引数などを使って外部から渡すDI/依存性の注入パターンを利用する場合も、注入するインスタンスの生成やクラスへの注入をサービスコンテナが担います。

バインドと解決

サービスコンテナにインスタンスの生成方法を登録する処理は「バインド(bind)」と呼ばれ、指定されたインスタンスをサービスコンテナが生成して返すことを「解決(resolve)」と呼ぶ。

サービスコンテナどこにあんの

Illuminate\Container\Containerクラスにサービスコンテナの機能の多くが実装されている。
しかし、実態はIlluminate\Foundation\Applicationクラスで定義されており、継承して使用している。

バインドについて

バインドにはいくつかの方法があります。
1.bindメソッド
2.bindfメソッド
3.singletonメソッド
4.whenメソッド

bindメソッド

もっとも利用される。第一引数に文字列、第二引数にインスタンスの生成処理をクロージャで指定します。
例)

app()->bind(Number::class,function(){
return new Number();
});

解決について

解決したインスタンスを取得する方法は以下の通りです。

1.makeメソッド
2.appヘルパ関数

makeメソッド

makeメソッドは引数に対象の文字列を指定します。メソッドを実行すると、指定された文字列にバインドされた処理を実行して、その戻り値を返します。

app()->bind(Number::class, functiuon(){
   return new Number();
});

$number1 = app()->make(Number:class);

DI(依存性の注入)って何？

例文で説明していきます。

下記はクラスが別クラスと依存関係にあるコードです。

<?php

class UserServices{
    public function notice($to, $message){
        $mailsender = new Mailsender();
        $meilsender -> send($to, $message);
    }
}

class MailSender{
    public function send($to, $message){
        // send mail・・・
    }
}
?>

noticeメソッドでMailSenderクラスのインスタンスを生成して利用します。
noticeメソッド、UserServicesの動作にはMailSenderクラスが必要です。
これが、UserServiceクラスはMailSenderクラスに依存している状態です。

何がダメなの？

アプリケーションの変更や拡張柔軟に対応するためには、拡張可能なプログラミング設計が不可欠です。
昨日やクラス同士が密接に依存する設計になっている場合、たった１つのクラスの差し替えがプログラミングに広範囲な影響を及ぼし、多くの修正やテストが必要になります。
ダメではないが、面倒極まりないし間違え易いということです。

どうすればいい？その１

noticeメソッドの引数としてMailSenderクラスのインスタンスを渡すように修正します。
コードで確認しましょう。

class UserServices{
    public function notice(MailSender $mailsender, $to, $message){
        $meilsender -> send($to, $message);
    }
}

引数でインスタンスを与えました。
noticeメソッドではMailSenderクラスだけではなく、その継承クラスも使用できるようになり、特定のクラスとの依存関係を排除できます。このようにクラスやメソッド内で利用する機能を外部から渡す設計パターンがDI(依存性の注入)です。

どうすればいい？その２

抽象クラス(インターフェース)に依存させることで、クラス間の関係はさらに疎結合となり、DIの恩恵をより受けることが可能になる。

class UserService{
    public function notice(NotifierInterface $notidier, $to, $message){
        $notifier -> send($to, $message);
    }
}

interface NotifierInterface{
    public function send($to, $message);
}

class MailSender implements NotifierInterface{
    public function send($to, $message){
           //send mail
    }
}

class PushSender implements NotifierInterface{  
    public function send($to, $message){
           //send push notdication
    }
}

「通知する」役割を担うNotifierInterfaceインターフェースを定義し、UserServiceクラスのnoticeメソッドの引数は、Notifierインターフェースへ依存するように変更しています。メール送信を行うMailSenderクラスとプッシュ通知を行うPushSenderクラスに対して、このインターフェースを実装しています。
この変更で、noticeメソッドに対してmNotifierInterfaceを実装したクラスであればなんでも引数として渡すことができます。

具象クラスではなく抽象クラス(インターフェース)に依存させることで、クラス間の関係はさらに疎結合となりDIの恩恵をより受けることが可能になります。

コンストラクタインジェクション

クラスのコンストラクタの引数でインスタンスを注入する方法を、コンストラクタインジェクションと呼びます。

メソッドインジェクション

難しいので後でかく

ER図を描こう

あるwebサービスの運用を他のチームに引き継ぐことになりまして、
ふとデータベースまわりのドキュメントがないことに気づきました。

とまあ、そんな状況でなくともER図を描くのは面倒です。

構築したテーブルから生成

統合環境等で作成もできますが、外部キーを張っていないと自動生成できません。
運用していたwebサービスは外部キーは張っていなくてアプリケーションでリレーションをしていたので、テーブルとカラムのリストまでしか読み込めません。

かといって専用のツールで描くと、MacとWindowsで共有できないことがありますし
Excelで作成するのはちょっと。。

SchemaSpy

SchemaSpyというツールを使いました。
これだと、DBから読み取れるところは読み取って、
追加でリレーションやカラムコメントを記述することができます。
[https://schemaspy.readthedocs.io/en/latest/configuration/schemaMeta.html]

また、設定ファイルや生成したファイルなどをリポジトリ管理することもできますし、
表示もブラウザなので、MacでもWindowsでも共有できます。

ER図を出力してみる

GitHubリポジトリ
[https://github.com/mya-zaki/laravel-schemaspy-sample]

環境

• PHP7.1
• Laravel5.5
• SQL Server 2017

構築

リポジトリをCloneする

DBのパスワードを編集
docker-compose.yml
schemaspy/schemaspy.properties
のを任意のパスワードに編集

コンテナをビルド

$ docker-compose up -d --build

DB作成

$ docker-compose exec sqlsrv /opt/mssql-tools/bin/sqlcmd -H localhost -U SA -Q "create database laraveldb"

パッケージをインストールする

$ docker-compose exec web composer install

.envをコピーして、編集

$ cp .env.example .env
$ docker-compose exec web php artisan key:generate

• DB_CONNECTION=sqlsrv
• DB_HOST=sqlsrv
• DB_PORT=1433
• DB_DATABASE=laraveldb
• DB_USERNAME=SA
• DB_PASSWORD=(DBのパスワード)

DBテーブル作成

$ docker-compose exec web php artisan migrate

SchemaSpyでデータベースドキュメント生成

準備ができたらSchemaSpyを実行します。
SQL Serverなのでドライバをschemaspy/drivers/mssql-jdbc-7.2.1.jre8.jarに置いてあります。
ドライバーはこちらから

XMLで情報追加

DBから読み取れない追加の情報についてschemaspy/schema-meta.xmlをおきます。

<?xml version="1.0" encoding="utf-8"?>
<schemaMeta xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://schemaspy.org/xsd/6/schemameta.xsd">
    <tables>
        <table name="users" comments="ユーザ情報">
            <column name="name" comments="ユーザ名"/>
        </table>
        <table name="posts">
            <column name="user_id">
                <foreignKey table="users" column="id"/>
            </column>
        </table>
    </tables>
</schemaMeta>

XMLにはusersテーブルとnameカラムにコメントを、postsテーブルに外部キーの設定が記載されています。

実行

DBの接続先、ドライバー、追加のXMLのパス、出力先はschemaspy/schemaspy.propertiesに。
ここでschemaspyコンテナを実行します。

$ docker-compose run --rm schemaspy

実行後、schemaspy/output/users.htmlをブラウザで開きます。

usersテーブルとnameカラムにXMLに記述したコメントが表示されています。

Relationshipsページへいくと、

usersとpostsがXMLに記載のとおりuser_idでつながっています。

これで、DBになくてもコメントやリレーションを表示できました！

XMLのリレーションの記述を自動で生成

SchemaSpy、かなり便利だと思うのですがテーブルが増えてくると
リレーションを記述したXMLを書くのが少々面倒です。

そこで、LaravelのEloquentのModelを継承したクラスのリレーションの実装からXMLを生成できるようパッケージを作りました。
mya-zaki/laravel-schemaspy-meta

以下の4つのメソッドが実装されている時にXMLに反映するようにしました。
hasOne
hasMany
belongsTo
belongsToMany

実行

$ docker-compose exec web php artisan schemaspy-meta:generate App\\Models --excludeClass=Flight --xmlFile=schemaspy/schema-meta.xml

XMLが更新されます。

<?xml version="1.0" encoding="utf-8"?>
<schemaMeta xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://schemaspy.org/xsd/6/schemameta.xsd">
    <tables>
        <table name="users" comments="ユーザ情報">
            <column name="name" comments="ユーザ名"/>
        </table>
        <table name="posts">
            <column name="user_id">
                <foreignKey table="users" column="id"/>
            </column>
        </table>
        <table name="comments">
            <column name="post_id">
                <foreignKey table="posts" column="id"/>
            </column>
            <column name="foreign_key">
                <foreignKey table="posts" column="other_key"/>
            </column>
        </table>
        <table name="password_resets">
            <column name="email">
                <foreignKey table="users" column="email"/>
            </column>
        </table>
        <table name="permission_role">
            <column name="r_id">
                <foreignKey table="roles" column="id"/>
            </column>
            <column name="p_id">
                <foreignKey table="permissions" column="id"/>
            </column>
        </table>
        <table name="my_phones">
            <column name="user_id">
                <foreignKey table="users" column="id"/>
            </column>
        </table>
        <table name="role_user">
            <column name="user_id">
                <foreignKey table="users" column="id"/>
            </column>
            <column name="role_id">
                <foreignKey table="roles" column="id"/>
            </column>
        </table>
    </tables>
</schemaMeta>

usersとpostsの記述のあとに、各テーブルのリレーションの情報が追加されました。
指定したXMLに追加分を上書きになるので、リレーションの記述の削除はされません。

もういちどschemaspyコンテナを実行します。

$ docker-compose run --rm schemaspy

Relationshipのページschemaspy/output/relationships.htmlを開くと

ER図が出来上がってます。

おわり

SchemaSpyとXMLの生成で完全自動化とはいきませんが
だいぶER図の作成が簡単になったと思います。

しっかり外部キーをはって構築していれば、
SSMSとかMySQL Workbenchとかが便利そうですが。

Laravekのバージョンを確認するコマンドの備忘録です。

php artisan --version

or

php artisan -V