[seasar-s2dao-dev:76] Re: Next S2Dao

[kubo]

久保です。

> > 自分は、
> > 
> >   A. DBは関連(1:n)で保存されている。
> >     ↓
> >   B. SQLでは、平坦に取得する。
> >     ↓
> >   C. 画面で関連(1:n)に展開する。※ここでは“DBと同じ持ち方の(1:n)”
> > 
> > というのがちょっとどうなんだろうって悩みます。
> 
> なるほど、必要性が理解できました。
> 1つだけに限っての1発SQL OneToManyは
> あってもよさそうですね。
> かなり限定されている&パフォーマンスの問題を起こしにくい
> のでトラブルメーカになることもなさそうです。

ありがとうございます。


> ManyToOne(OneToOne)は、最終的に利用されるときには、
> ほとんど平坦になるのでいらないということで良いでしょうか。

これに関しては、S2Daoだけのことを考えると「確かにそうです」
と答えざるを得ません。

Entity(Bean)で取得する最大のメリットは OneToMany であって、
ManyToOne ではないです。親テーブルがオブジェクトグラフで
いけない理由が見当たりません。


あえて言うとなると、

S2DaoのEntityを自動生成するツールからの視点だと、
親テーブルの列を取得するときの値の格納先(プロパティ)は、
親Entityへの参照経由で自動生成されています。
それにより、自分でEntityのプロパティを作成する手間を省いています。

> @Join("dept")
> public class EmployeeDto extends Employee {

しかし、この方法に関しては、そのような一括自動生成は
採用できません(しづらい)。なので、プロパティを自分で定義する方向と
なりますが、少し退化してしまう感がすこしあります。

ただ、この方法の方が、プロセスで必要な列だけを取得することができる
などメリットはたくさんあります。プロパティも一括自動生成でなく、
Doltengのように都度自動生成みたいな形で、いくらでもフォローは可能です。

なので、自動生成ツール利用の視点から言うと、
もし、S2DaoがManyToOne(n:1でEntityにMappingする)機能が無くなると、
親テーブルのEntityが目の前にいるのに(自動生成されてるのに)、
わざわざサブクラスにプロパティを作成して、かつ、その継承Entityを
戻り値にしたDaoのメソッドも作成するということになります。

S2Dao本体ではなく、S2Dao周りのプロダクトからの視点になってしまうので、
あまり説得力がない(or ここで発言すべきではない)かもしれません。
なので「あえて言うと」って感じです。




あんまり懸念ばっかり挙げても前向きにならないので、提案です。

Next-S2Daoが、完全に ManyToOneを止めるのではなく、

・デフォルトの「Next S2Dao」は、ManyToOneは無し。
・dao.diconでDaoMetaDataFactoryなどを差し替えるなどして
  Old-S2Dao仕様の動きを実現させることができる。

っていうのはどうでしょうか？

これなら別に自動生成ツールがどうのこうのではなく、
下位互換性を得ることができて、既存のS2Daoを使っている人にも
やさしいかなと思いました。




-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
kubo   <jazzflute ＠ mbn.nifty.com>
jflute <http://d.hatena.ne.jp/jflute>
株式会社ビルドシステム <http://www.buildsystem.co.jp>
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/