アカウント名:
パスワード:
S2Daoは優れた開発効率を実現できることで定評があり，一般に「S2Daoを使いたい」というのがSeasar2を採用する大きな理由になることが多い。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
S2Daoについて (スコア:3, 興味深い)
とありますが、実際に採用された現場の人たちの感想を聞いてみたいです。
S2Daoでは、親子関係(1:N)にあるテーブルを１回のSQLでJOINすると、クラスにN:1でマッピングされるため、子(N)のクラスのListが返却されてくる仕様なのですが、これをチームメンバーに理解して使いこなしてもらうのに、とても時間がかかりました。
しかも、この場合で親を複数件取得したい場合はN:1だとマッピングが複雑すぎて、使いこなしがとても難しかったです。
その上、1:N:Nのような３階層以上の構造を持つテーブルを１回のクエリでマッピングすることはできないため、何度もクエリを発行しなおしてマッピングせざるを得ませんでした。
iBATISだと、1:Nでマッピングできて親のクラスを戻り値として受取ることができるので、親を複数件取得するのも簡単です。また、1:N:Nのような構造でも１回のSQLでマッピングできます。
マッピングファイルがXMLで書かれるのでSQLだけでテストしたい際には、SQL定義を編集しないと実行できないっていう手間はありますが、一度実行してログを出力させてしまえばすむ話です。
個人的に、こういうフレームワークが大規模案件で採用されることは、フレームワークのその後の品質向上や、少ないドキュメント関係の問題解消に繋がる可能性があるので、とても喜ばしいのですが、「一般に「S2Daoを使いたい」」ってところだけが、ものすごく疑問に思いました。
Re:S2Daoについて (スコア:1, 興味深い)
http://laplace.4.dtiblog.com/blog-entry-26.html
複雑なSQLを使用しなければいけない場合SQLをそのまま記述できるみたいですし
ただ、自分も個人で触っているだけなので大規模案件でS2DAOがどのように使用できるのかはすごく気になります。
S2DAOについているサンプルコードがすごく単純なものなので大規模案件の場合どうしたらよいか疑問点は多くあるので。
今回のシステムをオープンソースに・・・・
ってのは無理だろうケド
その辺のノウハウを公開して欲しいと切実に思っています
Re:S2Daoについて (スコア:1, すばらしい洞察)
iBATISって、そうじゃなくSQLよりのDAOマッパーなので、SQLをどう使うかを細かく指定できるという意味では、そういう差は生じて当然って感じですよね。
でもそのトレードオフとして「面倒なSQLを書かされる」機会は増えてしまうわけで。
もともとOOPとSQLはインピーダンスミスマッチが激しいんだから、両方の良いところを十分に活かせて、しかも自動化できる、っていうマッパーは、なかなか作れないですよね。
>1:N:Nのような３階層以上の構造
すみません。それを一気に取得するってのを考えたこともありませんでしたm(__)m
確かに、遅延取得をしかけるんでもない限り、一気取りできるほうが(速度的に)優位ですね。
ただ、「多層のマッピングを自動化する」のも、Framework自体の開発段階で念頭に置いておけば、出来ないわけでもなさそうですね。ふむ。考えてみるか。
1:N:N (スコア:0)
Re:S2Daoについて (スコア:1)
Seaserは微妙に(大幅に?)使いましたがS2Daoは使わず
あえてS2Hibernate使いました。
(1)Hibernate使ったことがあるから
(2)Beanを自動生成するツールを使ったから
(3)逆にDAOを作ったことがなかった。
結局は慣れか(苦笑)
DAOの設計に慣れてるといいのかも知れませね。
でもつかわないかも。