マイクロフレームワークっぽく使う Symfony 4 事始め 4 ~RDB接続編~

Symfony 4 入門。前回の記事は以下

SymfonyでのRDB接続

Symfonyフレームワークでは公式で用意されているレシピではDoctrine (Doctrine DBAL / Doctrine ORM)に対応しています。Doctrine ORMではORマッピングを利用したRDB処理、Doctrine DBALではPHP PDOをラップしたようなものになっています。Doctrine DBALではPDO同様にMySQL / MariaDB / PostgreSQL 等に対して SQL を実行する以外に、SQLを生成するクエリビルダ―の機能も有ります。

また、DoctrineDBALの代わりに他の illuminate/database などを利用できるレシピも公開されているようです。

今回は簡単に使い始められる Doctrine DBAL で説明していきます。RDBには第1回でも説明したようにMySQL 8.0を利用しています。データは symfony_test DBを作成し、以下のような books テーブルを用意しています。

Doctrine DBAL の導入

これまでの実装でcomposer.jsonのrequire部分は以下のようになっています。

    "require": {
        "php": "^7.1.3",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "sensio/framework-extra-bundle": "^5.2",
        "symfony/console": "4.2.*",
        "symfony/debug-pack": "^1.0",
        "symfony/dotenv": "4.2.*",
        "symfony/flex": "^1.1",
        "symfony/framework-bundle": "4.2.*",
        "symfony/maker-bundle": "^1.11",
        "symfony/twig-bundle": "4.2.*",
        "symfony/web-server-bundle": "4.2.*",
        "symfony/yaml": "4.2.*"
    }

Doctrine DBALを利用するには symfony/orm-pack を導入します。名前から分かるようにDoctrine ORM / DBAL の機能はセットで導入されます。

composer require symfony/orm-pack

これで必要なパッケージ群が導入されました。

次にDB接続設定を行います。上記のログの最後にも出ている .env ファイル内に接続情報を記載します。Symfonyプロジェクト直下にある .env ファイルを開き、以下の部分を編集します。

DATABASE_URL=mysql://db_user:db_password@127.0.0.1:3306/db_name

db_user, db_password, 接続先ホストとポート、DB名を適宜変更したら保存します。なお、MySQLでの設定になっていますが、PostgreSQLなどに接続したい場合はこれも上記ログに出ている config/packages/doctrine.yaml で設定します。現在は以下のようになっています。

doctrine:
    dbal:
        # configure these for your database server
        driver: 'pdo_mysql'
        server_version: '5.7'
        charset: utf8mb4
        default_table_options:
            charset: utf8mb4
            collate: utf8mb4_unicode_ci

        url: '%env(resolve:DATABASE_URL)%'
    orm:
        auto_generate_proxy_classes: true
        naming_strategy: doctrine.orm.naming_strategy.underscore
        auto_mapping: true
        mappings:
            App:
                is_bundle: false
                type: annotation
                dir: '%kernel.project_dir%/src/Entity'
                prefix: 'App\Entity'
                alias: App

この設定の中で ‘%env(resolve:DATABASE_URL)%’ という部分が .env ファイルで設定した値が投入される部分になります。この yaml 設定ファイル自体に各種接続情報を定義する事も可能ですが、.envファイルに環境ごとの設定を入れておくことで環境ごとに切り替えをしやすくするような仕組みになっています。なお、.envファイルは初期状態だとGitリポジトリへのコミット対象ですが、 .env.local といったファイルを作ると .env.local は最初から Git Ignore されており、設定的にもそちらが優先されるようになっていますので開発環境などでは .env.local を使った方が良いかもしれません。

doctrine.yaml でのdriverの指定はデフォルトではPDO MySQLになっているのでPostgreSQLの場合はここをPDO PostgreSQLを使う設定に変更しておきます。

実際にRDBにアクセスしてみる

実際にDoctrine DBALを利用してRDBから値を取り出してみます。

リポジトリ

RDBへのアクセスはコントローラやサービスなどからも可能でべた書き出来るのですが、今回はアクセスするためのリポジトリとなるクラスを作成します。/src/Repository ディレクトリを作成し、BooksRepository.php を作成します。

<?php

namespace App\Repository\Impl;

use App\Repository\BooksRepository;

class BooksRepositoryImpl implements BooksRepository
{

    /** @var \Doctrine\DBAL\Connection connection */
    protected $db;

    /** @var Psr\Log\LoggerInterface logger */
    protected $logger;

    public function __construct(\Doctrine\DBAL\Connection $con, \Psr\Log\LoggerInterface $logger)
    {
        $this->db = $con;
        $this->logger = $logger;
    }

    public function get(int $book_id)
    {
        $sql = "SELECT * FROM books WHERE book_id = :book_id";

        $stmt = $this->db->prepare($sql);
        $stmt->bindValue("book_id", $book_id);
        $stmt->execute();

        $book = $stmt->fetch();

        return $book;
    }
}

DoctrineDBALではSELECT時に連想配列やオブジェクト、任意のクラスを元にしたオブジェクトなど様々な方法で値を返す事が出来ますが、今回はデフォルトの連想配列のまま扱います。変更する場合は Doctrine\DBAL\Driver\Statement::setFetchMode を呼び出します。

また、上記の例ではSQLの文字列に :book_id というプレースホルダを利用し、bindValue 関数で値を設定しています。この際に値が自動でエスケープされるので値を埋め込む際はプレースホルダを使うようにしましょう。また、DoctrineDBAL にはクエリビルダ機能が有るので、簡単なSQLであればクエリビルダを使って行ってもいいと思います。

コントローラ

順番通りに進めていれば Controller/RootController.php に以下の定義が既にあるはずです。無ければ追加します。

    /**
     * @Route("/books/detail/{book_id}/", name="book_detail", 
     * requirements={"book_id"="\d+"})
     */
    public function bookDetailAction($book_id)
    {
        return $this->render('books/detail.html.twig', [
            'book_id' => $book_id,
            'book_detail' => 'dumy text'
        ]);
    }

これをサービスクラスの呼び出しを追加します。サービスクラスに処理の中核となる部分を移し、コントローラではルーティングと送信されたデータの読み込み、ビューの呼び出しに専念させます(今回はIDを受け取ってDBからSELECTするだけですが)。

    /**
     * @Route("/books/detail/{book_id}/", name="book_detail", 
     * requirements={"book_id"="\d+"})
     */
    public function bookDetailAction($book_id, BooksService $booksService)
    {
        $book = $booksService->bookDetail($book_id);

        return $this->render('books/detail.html.twig', [
            'book_id' => $book_id,
            'book_detail' => $book
        ]);
    }

サービス

コントローラから呼び出され諸々の処理を行うサービスクラスを作ります。今回はリポジトリから値を受け取るだけです。/src/Service ディレクトリを作成し、BooksService.php を作成します。

<?php
namespace App\Service;

use App\Repository\BooksRepository;

class BooksService
{
    private $booksRepository;

    public function __construct(BooksRepository $booksRepository)
    {
        $this->booksRepository = $booksRepository;
    }

    public function bookDetail(int $book_id)
    {
        return $this->booksRepository->get($book_id);
    }
}

これでコントローラ、サービス、リポジトリの準備は完了です。該当URLにアクセスすると
RootController::bookDetailAction
BooksService:: bookDetail
BooksRepositoryImpl:: get
という段階を踏んでアクセスされます。最後にビュー detail.html.twig を調整しておきます。

{% extends 'base.html.twig' %}

{% block title %}Book Detail{% endblock %}

{% block body %}

<h1>Book Detail ID:{{ book_id }}</h1>
<p>
    <div>書籍名: {{ book_detail.book_name }}</div>
    <div>価格: {{ book_detail.book_price|number_format }}円</div>
    <div>発売日: {{ book_detail.book_release }}</div>
</p>

{% endblock %}

ではSymfonyのサーバーを起動し、アクセスを確認してみます。
php bin\console server:run
でビルトインサーバーを起動し、Webブラウザから http://127.0.0.1:8000/books/detail/1/ にアクセスします。

DBから取得した値を表示できました。導入方法としてはこのような感じでRDBに接続する事が出来ます。導入~SELECTまでの説明ですが、INSERTやUPDATE、DELETEもググりながら簡単に実装できるかと思います。とはいえDoctrine に関する日本語情報ってあまりないので増えてほしいなぁ……。

ここまでのソースの状態は以下を参照
https://github.com/lf-uraku-yuki/symfony4_tutorial/tree/tutorial04

なお、MySQL 8.0ではデフォルトの認証方法が変わった事も有り、「The server requested authentication method unknown to the client”」というエラーになる場合が有ります、これはググれば出てきます該当ユーザーの認証方法を caching_sha2_password から mysql_native_password を使った物に変更する事で回避可能です。

次回はログ出力について

Share this…

マイクロフレームワークっぽく使う Symfony 4 事始め 3 ~DIコンテナ編~

Symfony 4 入門。前回の記事は以下

マイクロフレームワークっぽく使う Symfony 4 事始め 2 ~ルーティング編~

Symfony 4 の DIコンテナ(サービスコンテナ)

今回は Symfony 4 の DIコンテナ(サービスコンテナ) について説明します。

ある程度のサイズのアプリケーションを構築する際にはコントローラとビュー(テンプレート)だけで処理が完結する事は少なく、具体的なロジックを別のクラスに移したり、データベースの読み書き部分を更に別のクラスに移したりといった設計をするかと思います。DIコンテナはそうしたオブジェクト間の依存関係に対して Dependency Injection (依存性注入) をしやすくするための仕組みです。

例えば機能Aに関する諸々を提供するサービスクラスAが更に別のオブジェクトや変数を必要とする(依存性がある)場合に、それらをサービスクラスA上で直接newせずにDIコンテナの機能を利用してサービスクラスAに注入する事で依存性が薄まり、テストコードが書きやすくなるなどのメリットが出てきます。

Symfony 4 のDI機能については config ディレクトリ内の services.yaml で定義されています。こちらを開いてみると以下のような定義が有ると思います。

services:
    # default configuration for services in *this* file
    _defaults:
        autowire: true      # Automatically injects dependencies in your services.
        autoconfigure: true # Automatically registers your services as commands, event subscribers, etc.

    # makes classes in src/ available to be used as services
    # this creates a service per class whose id is the fully-qualified class name
    App\:
        resource: '../src/*'
        exclude: '../src/{DependencyInjection,Entity,Migrations,Tests,Kernel.php}'

services.yaml 内の services: 内に自分で定義を書いていく事でも定義できるのですが autowire という機能によりその辺りはあまり意識せずに設定フリーで動かして行く事が出来ます。初期設定では App\ 名前空間配下であり ディレクトリは /src/ 配下の 「DependencyInjection」「Entity」「Migrations」「Tests」以外のディレクトリに切られたクラスであれば、自動でDIコンテナにクラスが登録されます。

DIコンテナに登録されたサービスは利用したいクラスのコンストラクタでコンストラクタインジェクション(コンストラクタの引数からクラスのフィールドに注入)したり、メソッドインジェクション(メソッドの引数からメソッド内に注入)したりして利用します。

例えばコントローラでルーティングを定義する場合に、リクエスト内容を利用するために引数に Request オブジェクトを受け取っていたと思います。このようにクラスの型を定義しておくことでDIコンテナが自動で必要なサービスを受け渡してくれます。

    /**
     * @Route("/books/detail/", name="book_detail_for_query")
     */
    public function bookDetailActionForQuery(Request $req)
    {
        $book_id = $req->query->get('book_id');

        return $this->render('books/detail.html.twig', [
            'book_id' => $book_id,
            'book_detail' => 'dumy text'
        ]);
    }

実際に利用してみる

これを自前で作成したサービスクラスで試してみます。以下のサービスクラスを定義します。
名前空間: App\Service
ファイル: src/Service/SampleService.php

<?php
namespace App\Serivce;

class SampleService
{
    public function helloWorld(): string
    {
        return 'hello world.';
    }

}

これをコントローラ上のルーティングから利用してみます。まずはメソッド(関数)インジェクションを試してみます。

    /**
     * @Route("/service/useService1", methods={"GET"})
     */
    public function useSerivce1(\App\Service\SampleService $sampleService)
    {
        $result = $sampleService->helloWorld();
        
        return $this->render('/serivce/use_service.html.twig', [
            'body' => $result
        ]);
    }

Twigテンプレートは以下です。bodyに渡した変数を表示するだけです。

<!DOCTYPE html>
<html lang="ja">
    <head>
        <meta charset="UTF-8">
        <title>{{ title|default('default title')}}</title>
    </head>
    <body>
        {{ body }}
    </body>
</html>

やっている事は引数に使いたいオブジェクトの型を指定しているだけです。これだけで Symfony のDIコンテナが SampleService のオブジェクトを注入してくれます。PHPビルトインサーバーを起動しWebブラウザから確認してみます。

しっかりサービスクラスのオブジェクトが利用できています。

次はコンストラクタでのインジェクションを試してみます。クラス内で恒常的に使うものはこちらの方がいいでしょう。

    // 利用するサービスクラスをコンストラクタインジェクションする
    private $sampleService;

    public function __construct(\App\Service\SampleService $sampleService)
    {
        $this->sampleService = $sampleService;
    }

    /**
     * @Route("/service/useService2", methods={"GET"})
     */
    public function useSerivce2()
    {
        $result = $this->sampleService->helloWorld();
        
        return $this->render('/service/use_service.html.twig', [
            'body' => $result
        ]);
    }

コンストラクタの引数でDIコンテナから受け取ったオブジェクトをフィールドに保存しておいて使います。書き方としてはあまり変わらないですね。

自動で登録され注入できる物の一覧はSymfonyのコンソールコマンド debug:autowiring 、自動登録以外もすべて含めての一覧は debug:container から確認できます。実際に試してみると結構いろいろなものが出てくると思います。例えば Request 以外にも、セッション(SessionInterface)であったり、ログファイルに書き込むロガー(LoggerInterface)であったりデータベース接続が設定済みである場合のデフォルトコネクションを取得したり出来ます。

また、上記の SessionInterface や LoggerInterface のように、インタフェースを実装したクラスである場合インタフェース名で注入するオブジェクトを指定する事が出来ます。インタフェース名で指定した場合でも SymfonyのDIコンテナは実際に実装した方のオブジェクトを渡してくれます。

設定値の注入

クラス名を持たない値を注入したい事が有ります。例えばメールを送信するクラスを初期化する際に送信元アドレスを固定で渡す仕様だったとします。

<?php
namespace App\Service;

class MailService
{
    private $from_address;

    public function __construct($from_address)
    {
        $this->from_address = $from_address;
    }
}

from_addressはメールアドレスを文字列として渡す仕様です。これだと型での指定ができませんし string 型を指定しても仕方が有りません。このような場合に services.yaml での手動定義が必要になってきます。parameters にパラメータを定義しておき、 services 内で「どのサービスの」「どの変数名に」「どのパラメータを渡すか」を指定します。

parameters:
    from_address: 'xxx@yyy.zzz'

services:

    # 既存で記載されているもろもろを中略

    App\Service\MailService:
        arguments:
            $from_address: '%from_address%'

この定義を追加する事で App\Serivce\MailService の引数 $from_address に対してパラメータ from_address を渡す事が出来ます。serivces.yaml での手動設定では他にも以下のような物に対して解決が行えます。

  • 一つのインタフェースに対して複数の実装が有る場合にどれを注入するか。
  • デフォルトではない方のDB接続を注入したい。
  • etc..

コンテナから直接取得する

コンテナに登録済みのオブジェクトは直接取得する事も出来ます。依存性は高くなりますがそうしたい場合もあるかと思いますので記載しておきます。

$sampleService = $this->container->get('App\Service\SampleService');
$from_address = $this->getParameter('from_address');

なお、上記の $this->container->get() で取りに行く方法はコントローラ内では制限が有り利用できないのでご注意ください。

実際のユースケースとしてはPHPUnitのテストコードを書く際に利用する事が多いです。PHPUnitテストコード内に対してはコンストラクタインジェクション、メソッドインジェクションを使った自動注入が機能しません。通常利用する TestCase クラスを継承した KernelTestCase を継承してテストを実装するとSymfonyのカーネルとDIコンテナを起動する事が可能になるので、そこから必要なオブジェクトを取得したり出来るようになります。これについては後でまた説明したいです。

その他の諸々

Symfony 4 をマイクロフレームワークとして使う場合、このDIコンテナ(サービスコンテナ)機能(とComposerによるオートロードの仕組み)がアプリケーションの機能を組み立てる骨組みになってくるかと思います。他にも説明していない様々な機能が有りますので、普通のインジェクション機能では解決できないものが出てきた場合は公式のドキュメントを参照してみてください。

Service Container (Symfony Docs)

ここまでのコードの状態は以下を参照してください。
https://github.com/lf-uraku-yuki/symfony4_tutorial/tree/tutorial03

次回はDB接続について書きたいです。

Share this…

朝自動カーテン開け機「mornin’ plus」を1カ月半ほど使ってみた

昨年末参加したの忘年会プレゼント交換で頂いた朝自動カーテン開け機「mornin’ plus」を1カ月半ほど使ってみました。タイマーを設定しておき、朝になると部屋のカーテンが自動で開く事で目覚めが良くなる?という感じのアイテムです。既存のカーテン・カーテンレールに工具など一切不要で取り付ける事が出来ます。ねじ回しすら要りません。

取り付け

どういう風に動くのかというと、カーテンレールにこれをぶら下げておくとタイマー動作で左右に動作してカーテンも一緒に開閉する、という仕組みです。写真を見た方が早いですね。

見ての通り部屋の内側からは見えず、ほとんど見た目が変わりません。部屋の外側からは見えますが「白い何かが付いているな」程度で特に気になるものではないかと思います。

ちなみに先代の「mornin’」では取り付けると手動での開閉が出来なくなる仕様だったらしいですが、 「mornin’ plus」 は取り付けた後も手でカーテンを開け閉めする事が出来ます、動かす際の抵抗もあまり変わらず特に困ることは無いかと思います。

乾電池で動作するので、高い場所など交換しづらい窓には取り付けない方がよさそうです。最初についてきた試供品の電池で1カ月半交換せずにいるので電池消費はそこまで大したこと無さそうですね。公式では6カ月程度動く事になっています。

タイマー設定

タイマーの設定は Android / iOS スマートフォン向けのアプリで設定します。「あまり有名ではないアイテム・サービスや企業の出すアプリ」としてはよくある事なのですが、まぁアプリのストアでの評判がよくない……。とはいえ私の環境で使う分には不具合なく問題なく動作しております。

「mornin’ plus」 初期設定の際はBluetoothで接続が必要ですが、それ以後はBluetooth接続は必要は有りません。 「mornin’ plus」 自体に時計が有り設定も自身に保存されます。

平日のみ動作するようなタイマーも設定可能。
初期設定ではどの方向に空けるか、どの程度の距離を移動するか(どの程度開けるか)なども設定します。

タイマー設定は開けるだけでなく閉める設定も可能なので、日中は自動で開けて夜は自動で閉めるなどして数日家を空ける際の防犯などにも良いかもしれません。

使用感

起きる時間よりも少し早い時間に空けた方が目覚めが良いらしいので起床用のタイマーより30分程度早い時間に設定。寝ている間に開いているので具体的な使用感というのはなかなか難しいですが、確かに気持ち目覚めが良くなったような気がします。起きる時間に部屋が明るいというのは気持ち「起きるかー」という感覚が強まります。当然雨の日などには日光が弱いので効果が落ちますが、それはそれで今日は天気が悪い日なんだなと肌をもって感じ取れます(?)

より具体的な部分として開け閉めする際の動作音ですが、ある程度のモーター音が鳴ります。熟睡していれば全く聞こえませんが、眠りが浅いと聴こえる、ぐらいの感じです。眠りが浅いと「あーカーテン開いてるなー、起きるほどじゃないけど」ぐらいには聴こえます。もっとも、起きる時間の手前なので起きるほど気になった時はそのまま起きてしまえば良いんじゃないかと。

価格もお手頃で初期設定をしてしまえばあとは半年に一回の電池交換だけなので、なかなかコスパのいい面白実用アイテムなんじゃないかと。仮に目覚めに効果が感じられなくてもカーテンレールにぶら下がっているので置き場所に困るようなことは無いし、朝に日の光を浴びておくのは悪くないものです。

 
Share this…