2019年3月

PythonエンジニアがPHPフレームワークSymfonyをざっくり紹介する

普段私はPythonDjangoで書くことが多いのですが、先日PHPSymfonyを触る機会がありました。

そこで今回は、普段Djangoを使っている目線でのSymfonyの構成などをざっくりご紹介したいと思います。

  1. まずSymfonyとは?

Symphonyではありません。Google先生に頼っていて思うような検索結果が出ていないときは、結構な確率でタイポしていたりします。

Symfonyとは、PHPのフレームワークの一つです。

PHPのフレームワークというと、日本ではLaravelCakePHPがメジャーですが、海外ではSymfonyも幅広く使われています。

Symfonyの設計思想はMVCModel View Controller)です。

DjangoMTVModel Template View)ですね。

役割的には

  • Model データ
  • ViewSymfony), Template 画面に表示されるもの
  • Controller, ViewDjangoModelView(Symfony)やTemplateに渡す部分

ざっくり上記になっています。名前が違ったり被っていたりするので分かりにくいですが、大まかな考え方は近しい部分があります。

  1. Symfonyの構造

ディレクトリ構成は大まかに以下のような形になっています

紹介解説用に番号を振っています

0. sample

├── 1. app                    

  ├── 1-1. Resources

    └── 1-1-1. views     

  └── 1-2. config             

├── 2. bin                    

├── 3. src                    

  └── 3-1. SampleBundle      

    ├── 3-1-1. Controller          

    ├── 3-1-2. Entity     

    ├── 3-1-3. Form            

    ├── 3-1-4. Resources

        └── 3-1-4-1. views   

    ├── 3-1-5. Service

    └── 3-1-6. Validator

├── 4. var                    

└── 5. vendor         

└── 6. web    

  • 0 sample

プロジェクトディレクトリになります

  • 1 app

ここに、プロジェクト全体で使用する設定ファイル(yamlなど)や、初期表示のindex.htmlを入れたりします。

細かい表示制御やデータの加工など各ページで使用するソースは基本的にこのディレクトリには置きません

  • 2 bin

コンソールで使用するコマンドなどのファイルを格納します。

  • 3 src

BundleごとにソースコードやHTMLファイルを格納します。主に開発をする際触るのはここになるかと思います。

  • 3-1 SampleBundle

そもそもBundleって何?と思う方も多いかと思われます。

簡潔にまとめると、Bundleとは、データベースと関連付いたエンティティや、ソースコードやテスト、画面に表示するHTMLなどのファイルをひとところにまとめた機能の塊です。

Djangoで言うところのアプリケーションに近いものだと思うと、想像しやすいかもしれません。

Bundle単位で機能拡張ソースコードも多く公開されているので、取捨選択することで自分でコードを書かずとも色々な機能を組み込めるようになっています。

  • 3-1-1 Controller

Djangoで言うところのView部分です。画面表示するデータを制御したり、URLのルーティング制御を行います。

  • 3-1-2 Entity

データベースのテーブルに応じたEntityを格納する場所です。getter, setterを設定したり、更新時のシーケンスなど、データベースの接続の際の付加処理を設定します。Djangoの方がこの部分に記載する処理の幅は広くなりがちですが、各アプリのmodels.pyに記載するような、データベースに応じたオブジェクトを定義する場所です。

  • 3-1-3 Form

画面で使用するFormを設定する部分です。ここで、各項目のバリデーションも設定するのですが、細かいバリデーション処理はまた別途記載したります。Djangoでいう各アプリのforms.pyに近い役割を担っています。

  • 3-1-4 Resources

viewsディレクトリに、HTMLファイルを格納します。

また、Bundle固有で使う設定ファイルなどある場合は、ここに置いたりも。

  • 3-1-5 Service

Serviceだったりhelperだったり、Bundle内の位置付けで名称は多々あるかと。

Controllerでやるには複雑な処理や、細かいビジネスロジックを記載していく部分になります。

  • 3-1-6 Validator

文字通り、バリデーションを記述する部分です。ここでバリデーションクラスを作成し、formの方でインポートして各項目へのバリデーションを設定します。

  • 4 var

キャッシュファイルや、ログファイルを格納しておくディレクトリになります。

  • 5 vendor

ライブラリ一般を格納するディレクトリになります。

  • 6 web

Jscss、画像ファイルなど、画面上から見えるファイルを格納する場所です。Djangoでいうstaticのような役割です。

  1. Symfonyのメリット・特徴

個人的に使っていてSymfonyってここが面白い!と感じた部分を取り上げてみます。

  • 分業がしやすい

画面表示はここ、バリデーションはここ、formの生成内容はここ、と細かく記述ファイルが分かれているので、多人数で分業をする際はコンフリクトを減らしやすいかと思います。また、Bundleごとに切り分けて開発を進める事も出来るため、開発方法の幅が広がります。

  • テンプレート言語のTwigが使いやすい

Djangotemplate記法と近しい、Twigが使えます。画面上でオブジェクトをループさせてテーブルに値を入れ込んだり、if分岐で表示するものを変えたり、生のHTMLでは表現しにくい処理が簡潔に行えます。

  • Formを使う機能を補助する仕組みが協力

検索であったりデータの登録・更新、ログインと、formを使わないシステムはほぼ無いかと思われます。Symfonyでは、Validationクラスで細かく設定してのバリデーションや、entityをまるっとフォームに入れてそれを使用してデータの更新を行う事、また画面にレンダリングする際も、細かくlabelform本体の配置は行えます。使い方のルールがある程度定まっている事で、多人数での開発の際にソースの揺れを減らせる事もメリットだと思います。

今までSymfonyの名前も知らなかったのですが、使ってみると意外と馴染んだ部分もありました。

PHPのメリットでありデメリットでもある自由にコードが書ける(≒フォーマットの統一が難しい)という部分を、Symfonyの記法である程度統一規格を持たせ一貫性のあるソースに仕上げやすいという風にうまくカバーしていました。

日本でのシェアが広くない事もあり、ドキュメントは少ないのでそこはお気をつけください。

もしPHPで開発を行う事がありましたら、フレームワークの選択肢の一つに検討してみてはいかがでしょうか?

2016/09/19PHP

PostgreSQLで階層マスタを扱う

とある案件で階層マスタを扱うことがありました。

DBがOracleの場合だと、「START WITH 〜 CONNECT BY PRIOR 〜」という、階層問い合わせの構文があるのですが、PostgreSQLだと階層問い合わせが出来るのか知らなかったので調べてみました。
(なお、MySQLでは使えません)

1. データを準備する

以下の様な階層構造を考えます。

レベル0 レベル1 レベル2
勘定科目
資産科目
現金
預金
負債科目
借入金
預り金
資本科目
資本金
利益剰余金


テーブル定義を以下の通りとします。

列名 内容
id int 主キー
code varchar(20) 科目コード
name varchar(100) 科目名
parent_id int 親科目の主キー (外部キー)


DDLは以下の通りです。

CREATE TABLE kamoku (
  id int primary key,
  code varchar(20),
  name varchar(100),
  parent_id int references kamoku(id)
);

INSERT文は以下になります。

INSERT INTO kamoku (id, code, name, parent_id) VALUES (1, 'A', '勘定科目', NULL);
INSERT INTO kamoku (id, code, name, parent_id) VALUES (2, 'A01', '資産科目', 1);
INSERT INTO kamoku (id, code, name, parent_id) VALUES (3, 'A02', '負債科目', 1);
INSERT INTO kamoku (id, code, name, parent_id) VALUES (4, 'A03', '資本科目', 1);
INSERT INTO kamoku (id, code, name, parent_id) VALUES (5, 'A0101', '現金', 2);
INSERT INTO kamoku (id, code, name, parent_id) VALUES (6, 'A0102', '預金', 2);
INSERT INTO kamoku (id, code, name, parent_id) VALUES (7, 'A0201', '借入金', 3);
INSERT INTO kamoku (id, code, name, parent_id) VALUES (8, 'A0202', '預り金', 3);
INSERT INTO kamoku (id, code, name, parent_id) VALUES (9, 'A0301', '資本金', 4);
INSERT INTO kamoku (id, code, name, parent_id) VALUES (10, 'A0302', '利益剰余金', 4);

こうして作ったデータをSELECTすると、以下の結果になります。

hoge=# select * from kamoku;

id code name parent_id
1 A 勘定科目
2 A01 資産科目 1
3 A02 負債科目 1
4 A03 資本科目 1
5 A0101 現金 2
6 A0102 預金 2
7 A0201 借入金 3
8 A0202 預り金 3
9 A0301 資本金 4
10 A0302 利益剰余金 4

(10 rows)

2. WITH RECURSIVE句による階層問い合わせ

PostgreSQLにはWITH句というサブクエリを定義する句が使えます。
ここに、RECURSIVEを付けると、再帰的なサブクエリを書くことが出来ます。

具体的には、以下の様に書きます。

WITH RECURSIVE child (level, id, code, name, parent_id) AS (
  SELECT 0, kamoku.id, kamoku.code, kamoku.name, kamoku.parent_id FROM kamoku WHERE kamoku.id = 1
UNION ALL
  SELECT
    child.level + 1,
    kamoku.id,
    kamoku.code,
    kamoku.name,
    kamoku.parent_id
  FROM
    kamoku, child
  WHERE
    kamoku.parent_id = child.id)
SELECT level, id, code, name, parent_id FROM child ORDER BY code;

結果は以下の通りです。

level id code name parent_id
0 1 A 勘定科目
1 2 A01 資産科目 1
2 5 A0101 現金 2
2 6 A0102 預金 2
1 3 A02    負債科目 1
2 7 A0201 借入金 3
2 8 A0202 預り金 3
1 4 A03    資本科目 1
2 9 A0301 資本金 4
2 10 A0302 利益剰余金 4

(10 rows)

2行目のSELECT文のWHERE句の条件が、開始のidになります。
開始のidを指定すれば、途中から取得することも出来ます。

WITH RECURSIVE child (level, id, code, name, parent_id) AS (
  SELECT 0, kamoku.id, kamoku.code, kamoku.name, kamoku.parent_id FROM kamoku WHERE kamoku.id = 2
UNION ALL
  SELECT
    child.level + 1,
    kamoku.id,
    kamoku.code,
    kamoku.name,
    kamoku.parent_id
  FROM
    kamoku, child
  WHERE
    kamoku.parent_id = child.id)
SELECT level, id, code, name, parent_id FROM child ORDER BY code;

level id code name parent_id
0 2 A01 資産科目 1
1 5 A0101 現金 2
1 6 A0102 預金 2

(3 rows)

逆順(子→親)も出来ます。

WITH RECURSIVE child (level, id, code, name, parent_id) AS (
  SELECT 0, kamoku.id, kamoku.code, kamoku.name, kamoku.parent_id FROM kamoku WHERE kamoku.id = 10
UNION ALL
  SELECT
    child.level + 1,
    kamoku.id,
    kamoku.code,
    kamoku.name,
    kamoku.parent_id
  FROM
    kamoku, child
  WHERE
    child.parent_id = kamoku.id)
SELECT level, id, code, name, parent_id FROM child ORDER BY code DESC;

level id code name parent_id
0 10 A0302 利益剰余金 4
1 4 A03 資本科目 1
2 1 A 勘定科目

(3 rows)

3. まとめと落とし穴

今回の階層問い合わせを再帰的に行うクエリだと、1クエリで出来て速度も速いので良い方法だと思います。

ですが、各階層(level)毎に取得している為、最後に並び替えをしないと、ツリー状に並ぶ結果が返ってきません。
今回は簡単にするために、科目コード(code)にルールを作って並ぶようにしています。

実際に使う時は、もう一工夫したいところです。

2016/09/19Database
1