読者です 読者をやめる 読者になる 読者になる

yohjizzz's Blog

I'm a Programmer.

なんとなく...

Teeda+S2DaoSAStruts+S2JDBCというように、
メインストリームが2つあってユーザを惑わせてしまうのが自分はよくないと感じてます。

選択肢が多すぎるのはなんだか敬遠されそうかなあと。
たぶん途中からS2.4の位置づけが若干変わってきているのではないかなあと思います。

スタックとして。部品として。 - ようじのにっき

たしかに「メインストリームが2つ」というのは言葉の意味と矛盾している。
さらに Seasar プロダクトにおいて「選択肢が多すぎる」ってのは良いことがないかもしれない。


でもどーなんだろう?


仮に S2JDBCSeasar における永続化フレームワークのメインストリームであったとしても、
S2Dao や Kunina、S2HibernateS2TopLink が存在して、進化を続ける以上、
S2JDBC ってのはコンテナにパッケージングされなくても良いんじゃないんだろうか...
S2Container と S2JDBC でちょこっとアプリを作ってみよ、なんてときに面倒くさいって話になるのかもしれないけど。
どーかな。
Maven があればライブラリの依存関係はクリアになるし、
なりよりも Dolteng の Chura があるのはそんなヒト(プロジェクト)の為なんじゃないだろうか。

Seasar にはたくさんのコンポーネントがあるよ。個別に使ってもらってもいいけどフルスタックだともっといいよ!」
「でも個別に準備して dicon いじるのはちょっと面倒だからさ。Chura 使ってみなよ!」
「こんなシステム開発には Teeda + S2Dao (with S2Dxo)だよ!」とか、
「あんなシステム開発には SAStruts + S2JDBC(with S2BeanUtils)だよ!」とかね。
プロダクトの組み合わせパターンが増えすぎるのは確かに混乱を招くことになるかもしれない。
ただ「増えすぎる」のと「明示的に数パターンを用意しておく」ことは別じゃないかな。


こんなコトを書いてはみたものの、
S2JDBC がコンテナにパッケージングされているのはきっと意味があることなんだろう。
S2Dxo と S2BeanUtils がコンテナにパッケージングされているのは S2JDBC とは違った理由だろうけど。

金曜日に、小林さんから、Teedaの拡張案を聞いたんですけど、結構すごい。
Entityと直接バインディングできるようになるので、
永続化されないプロパティ以外は、プロパティを宣言する必要がなくなります。
S2Dxoも使う必要がなくなるということです。詳しくは、小林さんが語ってくれるでしょう。

2008-02-03 - ひがやすを blog

Teeda も「Teeda + S2Dao (with S2Dxo)」から「Teeda + S2JDBC(without S2Dxo)」にシフトしていく感じなんだろうか。
それはそれで楽しみですw