細かいことはその時決めましょう

dev

http://d.hatena.ne.jp/higayasuo/

ひがさんがOOAとDOAのお話を書いてますが、僕が思ったのはHibernateとTorque（ついでにJoeyも）を使ったときのデザインのあり方です。


簡単に言っちゃえば、Hibernateはまずクラスを作る/想定して定義ファイルを書く/生成させます。んで、それにあわせたテーブルが作られる。

対してTorqueの方は、テーブルレイアウトをXMLで書いて、それに合うようなクラスを生成します。

（Hibernateでも テーブル -> 定義ファイル -> クラス ということもツールを使って出来るのは知ってるけど、今は発想のベースがどっちかって話ね）


新し物好きの僕としてはHibernateをひいきして「やっぱOO」とかってテキトーに言ってみてもいいんですけど、スタンスとしてはTorqueの方が分かりやすくていいなと思いました。

というのは、TABLE、COLUMN、INDEX、FOREIGN-KEY、UNIQUEなどのSQLになじみのある人ならすぐ分かるような言葉で定義ファイルが書けるからです。これなら定義ファイルの詳しい書き方なんてちゃんと知らなくても、すぐ理解して書けると思いました。


一人で開発するなら単純に自分の好みだけで判断していいんですが、実際のプロジェクトにおいてチームで共有するとなるとシステムデザインの共通理解が得られやすい方がいいっすよね。ミスも少ないし。

これは別にOOがダメだ、ということが言いたいんじゃなくて、ER図とかの方が実際に理解できる人が多いので、使いやすいっていう話です。


で、この辺が僕の意見なんですが、O/Rマッピングをするときは、デザインといってもDBのテーブルのデザインとマップされるクラスのデザインは、全く同一の構造を持つ必要はないっつうことっす。


例えばHibernateのmany-to-oneは、クラスでは他のオブジェクトへの参照で、DB上ではforeign-keyとほぼ同一に対応します。
しかしone-to-manyはDB上ではforeign-keyの逆方向を意味するだけで対応する何かがあるわけではありません（クラスではSetととかのCollectionに対応します）。


何が言いたいかっていうと、テーブルには双方向の関連が持てなくても、クラスとしては持っててもいいよね、ってだけのことです。
でもこれはO/Rマップの両端（オブジェクトとRDB）のことだけではなく、O/Rマップ自身のマップの仕方にも関係します（Hibernateだけな気もするけど）。

例えばRDBからデータをゲットするときに、関連するデータも一緒にゲットできると便利です。Hibernateはその辺を定義ファイルにone-to-manyだのmany-to-oneだのって書いとくと、自動的にゲットします。


しかし、常にリンクするデータ全てが欲しいわけではないのです。このone-to-many/many-to-oneの設定がクエリごとに設定できたら非常に便利なのに、どうも無理みたいです。

なのでJoeyはForeignKeyに対しては、簡単にone-to-many/many-to-oneの設定も使えるように、その部分をコメントアウトして設定ファイルを生成します。「one-to-many/many-to-oneは便利だけど、実際多用しない方がいいよね」っていうのがJoeyのスタンスです。


んで、クラスの方はそんなこととは関係なくForeignKeyに対して順方向はオブジェクトの参照を、逆方向はList（Hibernateの仕様のため内部的にはSet）を使えるようにします。


どんな風にデータをとってくるのかはコード次第。変に決まりを作るよりも、その時その時にあったコードが書けりゃいいかなと。Joeyはその部品を作るのを目標としよう。今決めました。