新年あけちゃいました…。

新年あけちゃいました…。

一筋縄ではいかないconvert

同じPHP、ベタ打ちからLaravelへのコンバートなんて簡単だろうと思っていたら…。

結構大変ですね。

年内に構築終わると思っていたのが大誤算です。

今回はコンバートで労力がかかっているポイントを整理してみたいと思います。

最大の難所は命名規制

結局、コンバート最大の敵はこの命名規制でした。

既に作成しているベタ打ちPHPではテーブル名を長くしたくなかったため独自の省略名称を利用していました。
これは、SQLを書く時に(長くない方が)煩雑にならない為だったのですが、Laravelでは単語の単数形/複数形の記載分けが出てくるため、そのまま利用できないことが多々ありました。
そこで、テーブル名やカラム名(特に参照先ID)をほぼ全て作り変える事となり、旧システムのSQLをすべて変えないといけない事態が発生。
ほぼセロベースで打ち込みとなりました。

ただ、命名規制を優先しないと旧システムの弱点と指摘された【セキュリティ】は課題を抱えたままとなりますし、変更修正を念頭に入れた設計とはなりません。

やはりコンバートには【ルール順守】のポリシーが必要なのだと感じています。

ビューのblade対応

次点はBladeへの対応です。

ベタ打ちシステムではPHP内にHTMLを書き込む感覚で作成していました。こんな感じです。

特に、HTMLパート内で出てくる<?PHP echo 変数 ;?>は都度echoを書く仕様なため面倒ですし、読み込むファイル毎にSQLを構築するという手間の多さも感じていました。

ここはMVCモデルのいいところで、SQLはmodelにある為、修正時に何か所も訂正する必要が無い強みがうれしかったです。

ただし、書き方が丸々変わるのでコンバートというよりゼロベースで書く事になります。
まぁ管理は楽になるのでしょうがないですね。

SQLのEloquant化

技術的に悩んだのがEloquantです。

いや、今でも悩みますね。「なんで値を取ってこないんだよ!」なんてことがまだあります。

1つのテーブルだけで済むものであればいいのですが、3つのテーブルのリレーションとか複雑さが増すとやはり直接SQLを組む方が楽です。
これは慣れなのでしょうけど、悩みます。

最大の利点は整理整頓

セキュリティーの脆弱性をつかれLaravelへのコンバートをするに至ったのですが、やってみて、最大のメリットは整理整頓だと感じています。

旧来のベタ打ちの場合、ファイルごとにリレーションが組まれます。
リレーションだけ取り出して require_once で呼び出す事も可能ですが、変数で値を可変させようとした場合は直接記載するのが定番です。
設計仕様変更でカラム名に変更があったり、1カラム減ったりなんかあった時には、影響するすべてのファイルを修正しなくてはいけません。
ファイルが煩雑に管理されてるとこの『全てを修正』の難易度が跳ね上がります。

Laravelをはじめ、MVCモデルではViewのファイルまで命名規制に含まれたりとルールが整理整頓を促してくれます。

まとめ

自由はいい事ですけど、自由過ぎると結局まとまらない。
そんないい例かもしれませんね。

年内に作り終えようと考えていたシステムは完成がだいぶ遅れる事となりますが、妥協することなく良いものを作っていきたいと思います。

それでは、本年もよろしくお願いいたします。