ZendFrameworkのざっくりとした歴史
ZF1
FrameworkでMVC！MVC！と言っていたあの頃。PHPエンジンを開発したZendのFrameworkということで今もPHP界隈では政治の中心的な立ち位置ですね。
composerが出る前の時代でしたので、これさえいれておけば他にいらないライブラリ集というオールインワンが圧倒的で便利でありました。
はじめは、Zend_DbのためにZF1を入れたのですが、いつの間にか他のコンポーネントを使い出していろいろ学ばせてもらってたのも良い思い出です。
ZF2
リリースされた当初、コンポーネントが分割できるようになったことに喜んでいたものですが、Zend\Dbの使い方がものすごく変わっていたのを見て唖然としました。
Adapterで手軽に使っていたメソッドが奥のクラス階層に移動していたり・・・
fetchするときも返り値がデータそのものではない時があったり・・・
普通に使うだけでも手順が増えてしまっていたのです。
これですぐ移行するという選択肢はなくなり、なんとか折り合いをつけてからにしようとしていたらZF1はサポートが延長され、折り合いをつける理由がなくなって今に至ります。
そしてZF3の絶望
PHP7や5.6が登場してライブラリも新しい世代へ変わることに動き出していた時期でしたので、ZendFrameworkの次期バージョンのZF3発表。
とりあえず作っているよ。というアナウンスがありZF2が生まれ変わるのか！と期待していたら、2系での延長上での開発でした。
ここでZend\Dbの使い勝手が変わることはなくなったのです。
ZF1がEOLに
Zend Framework 1 End-of-Life Announcement
ZF1の延長されてきたサポートが、ようやくといいますか、やっと9月にEOLを迎えるというアナウンスがされました。
SQL関係でセキュリティ上好ましくないことをしているなどありますので、ZF2や3にしろ他のライブラリにしろなにかしら移行する理由ができました。
折り合いをつけるには残念なところを変えてゆく
絶望を感じるところですが、メジャーな上、徳丸さんがとりあえずソース見てくれるところなので、切り捨てるというのはとりあえずなしで考えたら、どうやったら受け入れられるのか？使ってみようと思えるのか？考えました。
ZF2でよかった点
- オブジェクト指向やイベントハンドラ、DI意識されててZF1よりは設計良くなってたよ
- そのおかげでそれぞれの受け持ち範囲がわかりやすくなったよ
- select結果がIterator(ResultSet)で返されるので、データが大量の時に扱いやすくなったよ
ZF2でわるかった点
- 手順が全然変わったよ
- 公式マニュアルがひどいよ。ソース見ながら使った方が早いよ
- 今まですぐに届いていた関数が分散してたよ(例：beginTransaction)
基本的な使い方
- 主にSelect系SQL文を実行する場合→ Adapter
- Insert,Updateする場合→ AbstractTableで各DBテーブルのサブクラスを作る
- プログラマブルなSQLの組み立て→ Sql
Sql->prepareStatementForSqlObject($select)->execute() - TableのFeatureは、Eventで処理を追加できるよ
以上の方針にすると流れがわかりやすく、手順も最短ルートで呼び出してゆけるかと思います。が、メソッド名の長さなどイけてない部分はまだまだあります。
けどそれらをクリアするにはラッパークラスを作るしかないのか･･･
という残念なモチベーションでラッパークラスを作りました。
compatとついていますが、完全にZF1のインターフェースではないので互換とはいえないのです。
といいますのも、作ってる途中で過去仕様に捕らわれるのではなくZF2の良いところは本当に良くなっているので、そこは取り入れていくべきだと思ったからです。
具体的にAdapterでは全結果のarrayを返すfetchAllよりもイテレータを返すfetchResultを使うべきです。
移行するまでのつなぎとか、よく使っていたメソッドがどうなったのかソースを見ていただけるとわかっていただけるかと。ご参考までにどうぞ