第7回　保存先の変更 - OOP講座

続きまして。 SQL文を何も考えずに作ると、少なからぬ分量で「SQL-Injection」に見舞われる…という話は、以前にセキュリティ講座の第二回でやりました。
…もう３年も前の話なんですねぇびっくりです。
多くの場合「バインド機構/バインドメカニズム」という類のものが用意されていますので、そういったものを使うのが安全です。
もし自力で実装する場合(原則お薦めしませんが)、総ての必要な文字列に対して適切にエスケープ処理を漏れなく走らせる必要があります。「総ての必要な文字列に対して」「適切に」「漏れなく」で一瞬でもドキッとしたら、自力での実装は見直したほうが賢明です。

…と、ここらまではオブジェクト指向とRDBとの間に、あまり分厚い壁は存在しません。
この手のものは一般的にData Access Object(DAO)と呼ばれますし、PHPもPHP Data Objects(PDO)というものが提供されていますので。
PDOあたりは、使う使わないはともかく、一度はちゃんとマニュアルを読んでおくとよいでしょう。

そして…このあたりから、そろそろ壁が出てきます。
その壁とは「如何にしてデータを扱うか」という部分です。

是非は問いませんし、実際問題、賛否両論激しいものではありますが「オブジェクト関係マッピング」というものがあります。O/RM、ORM、O/Rマッパー、という呼称にすると「あぁ」と思われる方もいらっしゃるかもしれません。本稿では、以降ORMの略称をとりあえず用います。
先に「否」の意見を双方から持ち込みますと。

というのが論調の一つでしょうか(全部ではありませんので、興味がある方はググりつつ体験してみてください)。
この辺は、個人の見解から現場の好みまで色々ありますので、一概に何とか言えるようなものではありません。

ただ、虹色の見解のままだと原稿を進めていくにしても色々と差し障りますので。 筆者の作っているフレームワークでも使っています「OTM(Object-table mapping)」というあたりで一端手を打っておきたいと思います。
OTMはきっちり「筆者の造語」ですが。
大枠「後ろで複雑なSQLを書くほど便利なことはやってくれないけど、１つのテーブルとやり取りする時はオブジェクトでラッピングできる、程度には柔軟性を持たせてくれる」ものになります。
ある程度きっちりしたリレーショナルが欲しい場合、適宜classなりmethodなりでラッピングしつつ、一端「生のSQLを使う」形で実装をしていきます。

とりあえずOTM＋生SQLで作っておいて。
後で「SQL直接にして性能を追求する」もよし、「ORMでより便利かつ柔軟性なアプリケーションにする」もよし。
結局のところ「虹色な状況を担保した」ままの微妙な立ち位置で、しばらく進めていきたいと思います。

RDBとオブジェクト指向とのつながりを何となく整理したところで。
次回、実際にRDB回りの実装をやってみたいと思います！！