どうもどうも。2年近く連絡をしていなかったら育ての親である叔父が心配してきた伊藤です。
さて、WordPressにはデータベースを操作する機能というのは一応揃っています。
wpdbとかそのへんですね。ただ、基本的にはSQLを書くか、あるいは、WPのもともとのテーブル構造に対するクエリを前提としていることが多く、遠回りだったりとかしますわね。できればActiveRecordやORMがはいっているといいなーと思うわけです。
特に、従前のシステムがあって、WPでリニューアルをかけたい。というときは、従前のシステムのテーブルはそのままにリニューアルをしたいということは、多々あるわけです。
まさにそんな事を考えていたので、いっちょWordPressにORMを入れてみた。というはなしをします。
PHPのActiveRecord ORMライブラリ
PHPのActiveRecordやORMの単体ライブラリというのが、実はそもそもあまりないです。最近のPHPのフルスタックWebアプリケーションの場合、Doctrineがベースに利用されていたりとかするわけで、車輪の再開発を嫌うのか、あまりないのです。
僕の場合は、PHP5.3系の頃は、php-activerecordをよく使っていましたが、ちょっと古くなったのと、リレーションのリレーションが追えないなど、ちょっと足らないところもあります。
今回探していていい感じだなーとおもったのが、RedBeanPHPです。MySQL/MariaDBのプラグインとPHPライブラリを提供しており、かなり高速で、わかりやすいコード体系のORMになっています。しかし、MySQLのプラグインということで、共有ホスティングなどでは可搬性がさがりますので、今回は見送りました。
今回採用することにしたのがSpotORMです。Doctrine DBALをベースに作られたORMラッパーです。Relationの定義などがしやすく、僕がよく使うフレームワークYiiのModelの構造に似ているのも、採用の理由です。
ではインストール
composerでインストールします。
{ "require": { "vlucas/spot2": "~2.0" } }
とかですかね。composerの使い方はぐぐれ。
WPの場合は、functions.phpにコードを書く感じになるので、テンプレートディレクトリで実行すればよいかと思います。で、functions.phpの冒頭くらいに
require __DIR__.'/vendor/autoload.php';
とでも書いておけば良し。インストールが簡単です。
つかってみましょう
まず接続設定をします。
$cfg = new \Spot\Config(); $cfg->addConnection( 'mysql', 'mysql://ユーザー:パスワード@ホスト名/DB名' ); $spot = new \Spot\Locator($cfg);
DSNで書くとこんなかんじ。連想配列での指定ももちろん可能です。
設定はWPの接続情報を使い回すとかでもいいでしょう。
モデルを用意する
ORMなのでモデルクラスを用意します。
僕の場合は、functions.phpの並びに「Entity」フォルダを用意して、その中にモデルクラスを配置しました。オートローダーをとかを作るほどでもないので functions.phpに
$files = glob( __DIR__ .'/../Entity/*.php') ; if(!is_array($files)){ $files = array(); } foreach( $files as $one ){ require_once $one; }
を追記します。
Entityの中身を一気にロードしちゃっています。もちろん必要時に読むというやり方のが正しいとは思います。
Modelファイルの中身は
['type' => 'integer', 'primary' => true, 'autoincrement' => true], ]; } }
仮にこんなかんじです。fieldsになにかないと怒られることがある?っぽいので、primaryのIDだけ定義しておきました。
呼び出しに使ってみる
最後に実際にDBにクエリしてみましょう。
呼び出しをするfuncitonの中で
function hoge(){ global $spot; $postMapper = $spot->mapper('Entity\Products'); $row = $postMapper->where([ 'item_id' => '品番' ])->first(); return $row; }
こんな感じにかきます。上記例では商品DBに品番を問い合わせる。的な事をしています。
実際組み込んでいるがWPと融合しているわけではない
ここまで読むとPHPerならおわかりになるとおもいますが、WordPressのオブジェクトの他に、DBに対して接続を一つたてることになります。したがって、メモリ効率などは悪くなります。手軽さと、パフォーマンスどちらを優先するかなどで、選択することになるとおもいます。
しかし、DB操作をして、サイトデザインをWPに合わせるなどを考えると、有用ですし、SQLを書くよりはセキュリティ面でも安心してかけますね。
現場からは以上です。
コメントを残す