アカウント名:
パスワード:
S2Daoは優れた開発効率を実現できることで定評があり,一般に「S2Daoを使いたい」というのがSeasar2を採用する大きな理由になることが多い。
とありますが、実際に採用された現場の人たちの感想を聞いてみたいです。 S2Daoでは、親子関係(1:N)にあるテーブルを1回のSQLでJOINすると、クラスにN:1でマッピングされるため、子(N)のクラスのListが返却されてくる仕様なのですが、これをチームメンバーに理解して使いこなしてもらうのに、とても時間がかかりました。しかも、この場合で親を複数件取得したい場合はN:1だとマッピングが複雑すぎて、使いこな
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
S2Daoについて (スコア:3, 興味深い)
とありますが、実際に採用された現場の人たちの感想を聞いてみたいです。
S2Daoでは、親子関係(1:N)にあるテーブルを1回のSQLでJOINすると、クラスにN:1でマッピングされるため、子(N)のクラスのListが返却されてくる仕様なのですが、これをチームメンバーに理解して使いこなしてもらうのに、とても時間がかかりました。
しかも、この場合で親を複数件取得したい場合はN:1だとマッピングが複雑すぎて、使いこな
Re:S2Daoについて (スコア:1, すばらしい洞察)
iBATISって、そうじゃなくSQLよりのDAOマッパーなので、SQLをどう使うかを細かく指定できるという意味では、そういう差は生じて当然って感じですよね。
でもそのトレードオフとして「面倒なSQLを書かされる」機会は増えてしまうわけで。
もともとOOPとSQLはインピーダンスミスマッチが激しいんだから、両方の良いところを十分に活かせて、しかも自動化できる、っていうマッパーは、なかなか作れないですよね。
>1:N:Nのような3階層以上の構造
すみません。それを一気に取得するってのを考えたこともありませんでしたm(__)m
確かに、遅延取得をしかけるんでもない限り、一気取りできるほうが(速度的に)優位ですね。
ただ、「多層のマッピングを自動化する」のも、Framework自体の開発段階で念頭に置いておけば、出来ないわけでもなさそうですね。ふむ。考えてみるか。
1:N:N (スコア:0)