ひがやすを技術ブログ

電通国際情報サービスのプログラマ

ダイコン時代のORM - 結果セット中心

ダイコン時代のORM(O/R Mapping)はテーブル中心でもなければ、
オブジェクト中心でもなく、結果セット中心でなければならない。
結果セット中心とはどういうことだろうか。


業務にとっては、テーブルやオブジェクトがどのように設計されて
いるのかは、ある意味どうでも良いことだ。
自分達が欲しいデータ(結果セット)が画面に表示され、自分達が
入力したデータがどこかに格納されれば良い。
最も重要なのは結果セットをテーブルから取り出すことと、
テーブルに格納することなのだ。
結果セットはバウンダリ(画面など)に一時的に存在する状態といっても
いいだろう。もちろん、テーブルに関係ない値も
バウンダリには存在するけれども。
業務ごとにバウンダリは異なる、もちろん必要とされる結果セットも異なる。
そのため、任意の結果セットを柔軟にマッピングできるORMが必要になる。


テーブル中心のORMの代表はTorqueだろう。
このタイプのORMはテーブルごとに独自のクラスを割り当てる。
テーブル中心だとどうしても必要な結果セットを取得しにくいので、
使いづらい。
結局、テーブルから取ってきたデータを画面で使いやすい
ように別のオブジェクトにつめ直す必要がある。
別のオブジェクトにしない場合は、バウンダリで更新メソッドが
呼び出される危険もある。
終了ーーーーーーーーーーーーーーーー。


オブジェクト中心のORMの代表はHibernateだろう。
このタイプのORMは、ドメインモデルをPOJOで構成し、マッピング
駆使して永続化する。ドメインモデルと結果セットの間にも
インピーダンスミスマッチは存在するが、テーブルと結果セットとの
インピーダンスミスマッチに比べれば程度が軽い。
その業務にとって必要のないデータもあるが、なんとか結果セットに
マッピングすることは可能だろう。
このタイプのORMが(たぶん)一番コーディング量が少なくなる。
インピーダンスミスマッチの程度が軽い場合は、工数を削減できる。
しかし、実際は、インピーダンスミスマッチが大きい業務もあり、
結果セット中心のORMと併用する必要がある。
問題はここだ。
少数精鋭のチームの場合は、ORMを複数用いても適材適所で使い分けられるが、
大規模プロジェクトでは困難だ。
使い分けの指針を出しても結局現場は大混乱してしまう。
少数精鋭のチーム以外で使うのは危険だろう。


結果セット中心のORMの代表はiBATISだろう。
http://www.ibatis.com/common/sqlmaps2.html
知らないって(笑)。
Sqletも結果セット中心のORMだ。
知らないって(笑)。
DbUtilsもこのタイプに入れても良いだろう。

  • java.sql.ResultSetをJavaBeanかMapに割り当てる
  • INSERT, UPDATE, DELETE文のバインド変数にJavaBeanやMapのプロパティを割り当てる

のが特徴だ。
業務の立場からすると、SQLをかけば必要なデータが手に入り、
格納もできるので、どんな要件にも適用できる。
インピーダンスミスマッチに悩まされる必要もない。
このタイプのORMの問題点は、結果セットの入れ物だ。
結果セットごとにJavaBeansを作っていたらJavaBeansの数が
爆発してしまう。
しかし、ここでMap房を登場させてはならない。(笑)
Typesafeでない代償は、細かいところで積み上げられ結局大きく
なってしまう。


任意の結果セットを一定数のPOJOを使って処理するためには、
N:1(many to one)のマッピングができれば良い。
例えば、Department(deptno, dname, loc)、
Employee(empno, ename, job, sal, deptno)のテーブルがあったとしよう。
DepartmentとEmployeeは1:Nの関係だ。
empno, ename, sal, dnameを必要とする業務も、
empno, ename, job, dname, locを必要とする業務も
EmployeeとDepartmentのN:1マッピングで表現できる。
重要なのは任意の結果セット(カラムの組み合わせ)でこのマッピング
できることだ。Employeeに他にN:1にマッピングされているテーブルが
あった場合、必要なときにだけデータを取ってくるようになって
いなければならない。
この場合、lazy-loadingだと複数回、SELECT文が発行され、
パフォーマンスに問題が出る。1回のSQLでジョインしてデータを
持ってこなければならない。


また、オブジェクト中心のORMのようにインピーダンスミスマッチの
程度が小さい業務については、SQLは自動生成が良いだろう。


何だ結局S2Daoのことかよとお叱りの声が聞こえてきそうだ(笑)。
今ここで書いていることは、あくまでも私なりの視点だ。
ただし、かなり現実的だと思う。過去に実際のプロジェクトで
おこなった経験にもとづいているから。理想論ではなくね。