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

[kubo]

久保です。


若輩ながらコメントさせて頂きます。



> ・Genericsをつかうことで、任意のBeanをメソッドで
>   使えるようにする。

賛成です。


> ・メソッドのオーバーロードをサポートする。
>   同じ名前で複数のメソッドを定義できるようにする。

賛成です。


> Pagingは、Hibernateのように、DBMSの機能をできる限り
> 使い切る。

賛成です。


> また、S2Daoは、もともとSQLを中心にした
> シンプルなフレームワークなので、OneToManyなどの
> リッチな関連のサポートも、本来の方向性とは少し異なる気がします。

個人的な意見になってしまい大変申し訳ありませんが...

ユーザの立場からすると、SQL一発どりのOneToMany取得は
非常に魅力的なので、「OneToManyは今後サポートしない」と
いう話になると少々ガッカリするかもしれません。
現実のプロジェクトで要件としては非常に多いです。

ただ、実現は確かに簡単ではないので(単にパワー的にも)、
長い期間のずっと課題として残ってしまいがちですが、
「サポートしない」としてしまうのはちょっと寂しいです。

> SQLとJavaBeansとのマッピングに徹して、リッチな関連が
> 欲しければHibernateなどを使ってもらうようにしたほうが
> 棲み分けとしては分かりやすい気がします。
> 
> というわけで、Next S2Daoは、N:1の関連も止めて
> シンプルなSQLとJavaBeansのマッピングに徹する方向に
> 向かったほうがよいのではないかという提案です。

また、現実的に社内プロジェクトにおいて、
「あるプロジェクトはS2Dao、あるプロジェクトはHibernate」と
というわけにはいきません。教育コストなどのことを考えると、
「全てS2Dao もしくは 全てHibernate」という判断になりがちです。

もともと S2Dao を採用するということは、シンプルなものを
求めていると思われるので、方針としてシンプルを掲げるのは大賛成です。
ただ、最低限、開発で困窮しないような機能は備えていないと
いけない気がします。
その機能は何だ？と言われると、整理できてないのですが、
ManyToOne や OneToMany はその一つのような気がします。


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