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

[kubo]

久保です。

> > #
> > # 「S2Daoを採用するのかどうか」っていう議論を実業務で
> > # 結構やってきたので...ちょっと神経質なのです。
> > # (しかも出先と社内両方で)
> > # 
> > 
> 
> 久保さんが経験しているようなこと(S2Dao or Hibernate)は、
> 結構現場では多いのではないかと思います。
> 結局まるばつつけて機能が多いほうを選んでしまいがちなんですよね。

情報共有のためのせっかくの場なので：
(全てさらけ出しますね)

実際にO/R-Mapperの選定でAdviserとして関わったとき、
3社で、１勝１分け１敗（後に１敗は１勝に変わった）です。
「１敗」は、まさしく(S2Dao or Hibernate)で、Hibernateが採用されました。
単純なまるばつではなく、かなりS2Daoに理解を示してくれていたのですが、
・自動生成ツールがない
・OneToMany検索がない
という２つが決定的な理由でHibernateになってしまいました。
（それがきっかけで、自分でどうにかしようと思った）

「１分け」は、.NETしかやらない会社なのですが、
そもそも忙しい会社なのでずーっとペンディング状態。

「１勝」は、自動生成ツール付きでS2Dao採用(JavaとC#)

「後に１敗は１勝に変わった」も、自動生成ツール付きでS2Dao採用(Java)
  →結局色々あって１年後Hibernateは捨てられた。
  →C#の案件もS2Daoになりそうなムード。


やはり、どこの会社も視点は、
「今後うち(会社)はどのO/R-Mapperを使っていくか」
という視点でしたし、そうならざるを得ない現実は同感できます。



> 機能を多くしていくと、Hibernate系に近づくので、
> だったら標準のJPAを実装したほうがよさげと言う話になります。
> 
> Next S2Daoをシンプルに再構成するのは、賛否両論あるので、
> 一旦ペンディングにしたいと思います。

すいません、なんか自分が色々言ってしまって...
ただ、S2Daoを良くしていきたいという気持ちに変わりは無いです。

個人的な思いでは、2WAY-SQLは国際標準になってもいいじゃないかな！？
ってぐらいに思っている機能だったりします。



> 1.0への機能追加の要望もまだまだありそうなので、

自分も現状は、もう少し1.0の改善を続けて、
落ち着くのを待ってからの方がいいと思いました。


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