「インピーダンスミスマッチ」の本質は何か(1)
2001年にJavaを始めたときにむなしさを感じたのは、ResultSetの形で取得したデータをJavaBeanのプロパティに詰め替えるコードを書いていたとき。
以来、
- 永続化層から取り出したオブジェクトをそのままViewに渡すと期待通りにレンダリングできて、
- Viewから取り出したオブジェクトをそのまま永続化層に渡すとDBに書き込んでくれる
そういうフレームワークを誰か作らないかなーと寝っころがりながら待っていたのだが、出てこない。
ていうかJavaオブジェクトの永続化手法は2001年時点よりも混乱しているように見える。ポジティブな言い方をすれば百花繚乱である。なぜだろう？
JavaとRDBとのギャップの本質とは何なのだろう。
で、インピーダンスミスマッチ。
ざっと調べると、インピーダンスミスマッチという言葉には、狭義と広義の使われ方があるようだ。
狭義のインピーダンスミスマッチは、
- データベースフィールドとオブジェクトプロパティのマッピングをしなければならないこと
- 交差エンティティの居場所が、オブジェクトグラフ上にはないこと
ぐらいの意味で使われている。
要するに、O/Rマッパーの導入で解消する問題をインピーダンスミスマッチと呼んでいる。
O/Rマッパーは便利ですよ、という話の前振りでの使い方なので、当然そういう意味になる。
広義のインピーダンスミスマッチは、オブジェクト指向言語とRDBとの間のギャップ全般を指す。
これには、O/Rマッパーでは解消できない問題も含まれる。
具体的には
- 情報の関連づけ（リレーションシップ）が、オブジェクトは陽(explicit)だが、RDBは陰(implicit)
- オブジェクトには静的な型があるが、結果表のtupleには型がない（だから、テーブルを型と見なすしかない？？）
- アプリケーションが要求するオブジェクトグラフと、永続化したいオブジェクトグラフは違う
といった深い溝がある...て、これだけではなんだかよくわからないな。
これ以上書くには力が足りない。また調べものが必要。
でも、明日は仕事始めなのでここまで。
寝なきゃ...
行のデータをMapに収容するのはオブジェクト指向的でない、という話があるが本気か
上のエントリのために調べものしてたら、
O/Rマッパーを使わずに、ResultSetのデータをMapに収容するアプローチも あるが、これはオブジェクト指向的ではない。 Javaを使うメリットを放棄していることになるので、やめましょう。
みたいな意見のテキストが複数出てきたのだが、これは本当だろうか。
結果表の行単位には、データと一緒にカプセル化すべき手続きなんて大したものはない。
getterならフォーマット処理（金額の3桁ごとにカンマを入れて返すとか）、setterならバリデーションぐらいか。
本当にやりたいこと＝ビジネスロジックは、むしろ結果表全体に対して存在する。
そう考えると、多くのO/Rマッパーが
- 行データに対しては任意のオブジェクトをマップし
- 結果表全体にはただのjava.util.Listをマップする
というのは何か変な感じがする。
行データをMapに収容するのがオブジェクト指向的でないなら、
結果表をListに収容するのもオブジェクト指向的じゃないのではないか。
私はサービス／データ分離派なので、結果表はただのListに収容してもらったほうがありがたいと思っているのだが。
