国産オープンソースDIコンテナSeasar V2(S2)

1 名前：デフォルトの名無しさん mailto:sage [04/08/09 18:36] 一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。 ってどうよ？みんなもう使ってるの？ 最近、気になるのでスレ立てました。 使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。 それではスタート！ 本家 seasar.org www.seasar.org/ Seasar Projectグループ seasarproject.g.hatena.ne.jp/ 関連スレ(なのか?) Java Spring Frameworkを語るスレ pc5.2ch.net/test/read.cgi/tech/1077465099/ Java⇔RDBのMapping-Frameworkを語るThre Vol.3 pc5.2ch.net/test/read.cgi/tech/1090653286/ 702 名前：デフォルトの名無しさん mailto:sage [04/10/20 23:09:40] ひがさんやはぶさんの名前を出す必要もないけどな S2の話題でﾏﾀｰﾘやろうや。からさわぎ楽しみ。 703 名前：デフォルトの名無しさん mailto:sage [04/10/20 23:12:53] やっぱりからさわぎはくーすのトラックが人気なのかな？ 俺もデザイントラックにしようかと思ったんだけど くーすは本が出るからそっち読むとして 今回はビジネストラックにしようかなとも思って。 マジカ面白かったし。 704 名前：デフォルトの名無しさん mailto:sage [04/10/21 00:08:30] S2JSF いつ頃だろうか。 前のプロジェクト、プレゼンテーション層までSpring使うんじゃなかった orz 705 名前：デフォルトの名無しさん mailto:sage [04/10/21 00:11:39] >>704は>>700に助けてもらえ 706 名前：デフォルトの名無しさん mailto:sage [04/10/21 00:33:30] 今のうちにS2に乗り換えてしまくて。 WW2かTapestry試そうかと思ったが、本命はS2JSFなんだよな。 タイミング的に微妙..... 707 名前：デフォルトの名無しさん mailto:sage [04/10/21 00:52:05] 何かに依存した設計のデメリットを、ロッドジョンソンに身を以て教えられた。 そんな２７歳の秋。 708 名前：デフォルトの名無しさん mailto:sage [04/10/21 01:22:30] この板以外、どこのブログ見りゃいいんじゃいの？押さえどころ 709 名前：デフォルトの名無しさん [04/10/21 02:45:56] ドメインロジックとSQL capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL くーすマンセーな人は、一度↑を読んでみて欲しい。 それで、TransactionScriptと DomainModelの長所短所を理解した上で TransactionScriptを使っていただきたいなー。 710 名前：デフォルトの名無しさん [04/10/21 06:08:00] 大田@会社さんへのレスというわけではないのだけど。 >>692 > 理想は，でも現実的には，だったらどうしたらよい > という前向きな人たちの集まりだと思うのだけど。 傍から見てると 「理想=OOA/D」は幻想だった、これからは TransactionScriptマンセー って言っているように見えちゃうのは俺だけ? # TransactionScriptが最適解である状況が存在することは否定しないけどさ 711 名前：710 [04/10/21 06:19:20] 間違えた。 以下のとおりに修正。 >ひがさんとはぶさんを傍から見てると >「理想=OOA/D」は幻想だった、これからは TransactionScriptマンセー >って言っているように見えちゃうのは俺だけ? 712 名前：デフォルトの名無しさん mailto:sage [04/10/21 09:08:50] はぶ氏がRDB大好きだというのはblog見てるとわかる。 ひが氏はもう少しニュートラルというか使いやすい ORマッピングを考えてのことなんじゃないかな。 ふたりともTransactionScriptマンセーというのとはまた違う気がする。 ER分析マンセーなのかも知れないが。 713 名前：デフォルトの名無しさん mailto:sage [04/10/21 10:03:23] RDBをRDBとして使う限りにおいては、ER分析マンセーみたいね。 俺も同意。つーか当たり前だと思う。 RDBをただのストレージとして使うやり方は俺には合わんかったんでｼﾗﾈ。 714 名前：太田＠会社 mailto:oota_ken@hotmail.com [04/10/21 10:37:12] 710さん> 幻想というより西方浄土でしょうか。ひがさんにダイレクトに聞いてみると分かりますが， TransactionScriptマンセーじゃないですね。僕も今は教育側にいるときがありますけど， 理想のOOA/Dは現時点ではあまりに属人性がありすぎて，Martin Folwerのいる会社のような よほどつわものがそろった組織でないと難しいです。つわものがそろっていれば，理想の OOA/Dも不可能ではないと思います。 >capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL 既読です。読書会でも話題になりました。これをたたき台にして，トレードオフについても かなり議論になりました。理想のOOAD対ER分析というよりはメンテナンス性対パフォーマンス というところでしょうか。 715 名前：デフォルトの名無しさん mailto:sage [04/10/21 11:11:11] 単に選択の問題であるだけでしょう。 私が今携わっているプロジェクトでは業務ロジックがさほど多くなかったので、 Springを使ったTransactionScriptな設計にしてありますが、 明らかにサービス層の肥大化が予想される場所にはDomainModelを適用しています。 別にどちらが正解であるということもありませんが、OOエキスパートが少ない 環境ではTransactionScript寄りになってしまうことは避けられないでしょうね。 ちなみにくーすはTransactionScriptの発展的なアプローチだろうと思います。 ひがさんは否定しておられるようですが、サービス層と永続化層を分離した パターンの中で、大別して上記２つ以外に思いつくものはありません。 というか何がどう違うのかもうちょっと説明して欲しいかも。 Entity層にビジネスロジックを含めないって時点で、少なくとも DomainModelではないし。 今日は風邪で休んでるんで自宅からカキコ。 直に書きに行こうかともおもったけど私なんかの出る幕はではなさそうだし、 この場で失礼。 716 名前：デフォルトの名無しさん mailto:sage [04/10/21 11:15:59] ビジネスロジックって表現がそもそも曖昧だよな 717 名前：715 mailto:sage [04/10/21 11:24:03] >>716 > ビジネスロジックって表現がそもそも曖昧だよな そうかも。 私の中では一連の"業務仕様"ってところで理解してます。 売上げ本数の計上ルールとか？ いい例えが思い浮かばん。 永続化処理とか、メールやCSV取込とかはビジネスロジックとは 呼べないでしょうね。 718 名前：715 mailto:sage [04/10/21 19:00:45] 本当に答えて貰ってたんで、ちょっと感激してしまった。 私自身、2chにもカキコすることなんて滅多にないから。 なるほど。 というところですが、時間があればひがさんにもPofEAAの一読をお勧めしたいです。 文章を読む限り、原書の方にはまだ目を通されていないような印象でしたので。 リッチなSQLはDomainModelにもTransactionScriptにも適用されます。 そこでの問題はロジックがSQL内に分散することですが、これがパフォーマンスとの。 トレードオフだと言っているわけで、それはDomainModelにしろTransactionScriptにしろ 同じことです。 ところで、このスレのちょっと上のあたりでDomainModelとDTOとの相互変換云々って 話で盛り上がってたようですね。 私はよく、DomainModelをDTO(テーブルと同じ構造)を内部に複数持ち、 各層に公開するインターフェースを実装したオブジェクトとして定義することがあります。 というか大体これです。 相互変換の必要がないインチキ手抜き設計なので、当然無駄なプロパティや処理が 増えることになりますが、要の部分はインターフェースを介して隠蔽されているため、 実際に問題になるような事は滅多にありません。 Springの各種DaoSupportやS2Daoもそのままの形で適用出来ます。まあ参考までに。 純粋なDomainModelはO/RMapperの発展に合わせて、今後少しずつでも浸透して行くでしょう。 と願ってみる(希望的観測) 719 名前：デフォルトの名無しさん mailto:sage [04/10/21 20:37:11] 結論：OO厨は邪魔なだけ。 720 名前：デフォルトの名無しさん mailto:sage [04/10/21 21:44:57] ちゃんとした手法に基づいてやられたら、デスマーチのらくらく残業ができなくなるもんね。 721 名前：デフォルトの名無しさん mailto:sage [04/10/21 22:00:20] ここんところの話が英単語ばっかりでよくわかんにゃい。 くーすの考え方の肝ってどっかに載ってる？ 「業務処理手順をソフトウェア設計者が抽象化してはいけない」ってことかな、と思ってるんだけど。 OOは部品化以外の用途で仕事で使うには、頭がよい人を期待しすぎだよ。 自分で設計してるときはそりゃ楽しいけど、実働後の保守メンバーに馬鹿が１人いただけで設計が崩壊しかねない。 それが自分だったりして鬱になる。 例えると、天才が設計したゼロ戦で華麗に舞って死ぬよりも、 芸が無いグラマンでデスマから生還したほうがいい。 722 名前：デフォルトの名無しさん mailto:sage [04/10/21 22:14:52] その例えだと、グラマンはいかにも燃費が悪い。 ぜいたくに出来た飛行機だと松本零二も言ってます ↑ ここ笑うところ 723 名前：デフォルトの名無しさん mailto:sage [04/10/21 22:58:25] >>721 その、グラマンたるライブラリがSeasar2なんだよ！ POJO書いて、設定ファイルを書くだけ。 S2で欲しい機能があれば、はてなでｷﾎﾞﾝﾇするだけでOK。 724 名前：デフォルトの名無しさん mailto:sage [04/10/21 23:48:09] ひが氏にお願いです。 商用サポートもドキュメント見直しもFlexも くーす本もからさわぎも全部後回しでいい。 頼むからS2JSFを早く出してください。おながいします。 725 名前：デフォルトの名無しさん mailto:sage [04/10/22 00:28:45] >>724 S2JSF ＞ くーす本 ＞＞＞＞＞＞ その他 726 名前：デフォルトの名無しさん mailto:sage [04/10/22 00:41:18] 開発するより宗教論争が好きな人って結構いるね。 727 名前：デフォルトの名無しさん mailto:sage [04/10/22 00:52:30] 2chに書いてるﾔｼなんざ大抵そうだな 728 名前：デフォルトの名無しさん mailto:sage [04/10/22 01:04:27] つか、2ちゃんだから出来るんだよ。 現場でやる奴よりは全然いい。 大体宗教論争ってのは、スプーンに天使は 何人乗る事が出来るかとか そういうアホで無意味な事を議論する事で、 ここでの話はわりと意義はあると思うよ。 729 名前：デフォルトの名無しさん mailto:sage [04/10/22 01:04:56] >>726 開発なんかするより他人を論破することが楽しいですが何か？ 730 名前：デフォルトの名無しさん mailto:sage [04/10/22 01:20:59] >>729 hub。 731 名前：デフォルトの名無しさん mailto:sage [04/10/22 01:32:03] >>721 > ここんところの話が英単語ばっかりでよくわかんにゃい。 www.martinfowler.com/eaaCatalog/ > くーすの考え方の肝ってどっかに載ってる？ > 「業務処理手順をソフトウェア設計者が抽象化してはいけない」ってことかな、と思ってるんだけど。 www.wikiroom.com/tpircs/?cmd=read&page=higa%A4%B5%A4%F3%A4%CB%A4%E8%A4%EB%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%CA%FD%CB%A1&word=higa%A4%B5%A4%F3%A4%CB%A4%E8%A4%EB%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%CA%FD%CB%A1 732 名前：デフォルトの名無しさん mailto:sage [04/10/22 01:45:02] ttp://d.hatena.ne.jp/higayasuo/20041021#1098336935 うそーん。ぜんぜん問題わかってないじゃん。 だまされたと思って一回原典読んでみてください。お願いします。 733 名前：デフォルトの名無しさん mailto:sage [04/10/22 01:51:36] ttp://d.hatena.ne.jp/higayasuo/ > 良く使われると思われるドキュメントを見直しました。 > すべて、概要、リファレンス、Exampleの3部構成になっています。 > どうでしょう。2chの人 おぉ、こぎれいに、丁寧になってる。 くるしゅうないぞよ。 あとは、www.seasar.orgにそういった改変情報が載るようにすることですね。 それから、ソースと実行結果はスタイルを変えたほうが。 実行結果は黒地白文字とか。 734 名前：デフォルトの名無しさん mailto:sage [04/10/22 02:04:34] 733のような奴の言うこと真に受けて、がんばってらっしゃる。 ひがさん、尊敬します。 733のような下らない連中は奇麗なドキュメント作っても、大して理解できる訳でもなく、ただ単に新しい技術を斜め読みして、あーだこーだ言うだけで、結局まともに動くプログラムを作ることすらできないですから。残念！ 735 名前：デフォルトの名無しさん mailto:sage [04/10/22 02:17:22] >>734 > 733のような奴の言うこと真に受けて、がんばってらっしゃる。 > ひがさん、尊敬します。 >>733って、文体は2ch的で一見失礼だけど、ひが氏のモチベーション向上+ 前向きな成果物改善支援の意図が感じられる好レスだと思うんだが。 > 733のような下らない連中は奇麗なドキュメント作っても、大して理解できる訳でもなく、 > ただ単に新しい技術を斜め読みして、あーだこーだ言うだけで、結局まともに動く > プログラムを作ることすらできないですから。残念！ こういう非生産的なラベリングはやめようよ。つーわけで>>733気にするな。 って、>>733の自演扱いされるのがオチか。 736 名前：デフォルトの名無しさん mailto:sage [04/10/22 02:19:11] >> バウンダリで、直接ドメインオブジェクトを使うのも、かなり困難だと思います。 これって理由は何でだっけ？ 737 名前：デフォルトの名無しさん mailto:sage [04/10/22 02:35:11] >>735 >ひが氏のモチベーション向上+ >前向きな成果物改善支援の意図が感じられる好レスだと思うんだが。 ドキュメント的には、「今の段階で」十分すぎるほど揃ってると思う。 日本語ということも含めると、他のオープンソースプロジェクトなんかより 断然素晴らしい。 失礼な文体、普通はモチベーション下がるって。成果物改善支援？大きく出たな。 物は言いようか。好レス？？笑けた。ネタ？ 738 名前：733 mailto:sage [04/10/22 02:37:38] >>735 ありがとー。 あーだこーだ言うだけ言って、作業に手は貸さないわけだから、そこに対して改善が図られた場合には、ちゃんと気づいて反応するようにしてるです。 739 名前：デフォルトの名無しさん mailto:sage [04/10/22 02:40:58] 「今の段階で」というなら、「揃っている」じゃなくて「揃った」、の方があてはまるんじゃねぇの？ 740 名前：デフォルトの名無しさん mailto:sage [04/10/22 02:50:08] >>736 あとで仕様変更があってバウンダリとドメインオブジェクトの間にロジック（サービス）を 挟まなくちゃいけなくなった時に困るからじゃなかったっけ。 741 名前：デフォルトの名無しさん mailto:sage [04/10/22 03:06:07] 「今の段階としては」だな。 742 名前：デフォルトの名無しさん [04/10/22 06:11:18] d.hatena.ne.jp/higayasuo/20041021#1098310525 > リソース層にRDBMSを使う限り、SQLの知識は必須です。 > デザインパターンやP of EAAの習得には熱心だけど、 > SQLには興味ないなんて人がいるなら、知識のバランスに > かけてます。 d.hatena.ne.jp/habuakihiro/20041021#1098369060 > JSPバリバリですぅ〜。でもServletはわかりませ〜ん。ってのと、 > ORマッピングツールバリバリですぅ〜。でもSQLはわかりませ〜ん。 > っていうのは、似たり寄ったりだと思うんだが、 お二人とも勘違いなさっているようですけど、 DomainModelを推している人たちは 「SQLが分からないから使わない」 んじゃなくて 「SQLにビジネスロジックを入れたくないから使わない」 んです。 RDBMSを使っている限りはSQLの知識が必須なのは当然でしょう。 743 名前：デフォルトの名無しさん mailto:sage [04/10/22 06:50:50] >>732 問題と思うことをきちんと指摘したら。 人にいわれる本を全部読むような時間のあるひとはいないだろ。 744 名前：デフォルトの名無しさん mailto:sage [04/10/22 07:09:24] >742 推している人たちって誰のこと？ DomainModelいいよ！って言ってる人全部ってわけじゃないでしょ？ SQL書きたくないから〜って人は確実にいる（何人か知ってる）し、 そういう人を想定して言ってるんじゃないかな。 SQLばっちり分かっててかつDomainModelを推してる人よりは多いと 感覚的には思うが、どうだろね。 745 名前：デフォルトの名無しさん mailto:sage [04/10/22 07:52:08] >>742 DomainModelを推している人は、 「SQLが分からないから使わない」 と思っているとは、書いてないと思うけど。 それは、被害妄想。 746 名前：デフォルトの名無しさん mailto:sage [04/10/22 08:27:37] >>735 我田引水 747 名前：デフォルトの名無しさん mailto:sage [04/10/22 08:30:03] >>742 なあビジネスロジックって何？ ほんとにわかんねえんだよ。 SQLで平均とか一発で出せても 使うなってことか？平均何とかも ビジネスロジックだと思うんだけど。 748 名前：デフォルトの名無しさん mailto:sage [04/10/22 08:34:15] 何でこのスレはageる人が多いんだ？ 749 名前：デフォルトの名無しさん mailto:sage [04/10/22 09:00:30] >>732 ひがたんはそんなの読まなくてもいいからS2JSFを先に作って欲しい。 正直漏れはくーすはどうでもいい。便利な道具としてのS2が気に入ってるんだ。 もしひが氏が真面目に原典とやらを読んだ結果S2JSFのリリースが遅れたりしたら >>732ぬっころす 750 名前：デフォルトの名無しさん mailto:sage [04/10/22 09:20:50] そこまで粘着すると、キモいね。 751 名前：デフォルトの名無しさん mailto:sage [04/10/22 09:32:31] 2chに書いてるだけでキモいけどね とりあえずこのスレは粘着のスクツということでFA 752 名前：デフォルトの名無しさん mailto:sage [04/10/22 10:35:49] >>747 そういうことみたいだな。 複雑な会計の帳票とか出すとき どうするんだろうって思うよ。 UNIONとかFROM句にサブクエリとか ガンガン書いてやっとまともなレスポンスで 出るようになる帳票とか山ほどある。 だからS2Daoは、最初見たとき霧が晴れた気分でした。 753 名前：デフォルトの名無しさん mailto:sage [04/10/22 10:42:12] ドキュメントがいくつか更新されたみたいです。 ・DIContainer ・AOP ・テスト技法 ・S2DAO の4項目かな？ どこの項目が更新されたかわかるように印をつけて（updateとかnewとか） くれるとありがたいなあ･･･ 754 名前：デフォルトの名無しさん mailto:sage [04/10/22 10:59:46] >>753 >>733で既出。そこのブログにリリースノートが。 755 名前：デフォルトの名無しさん mailto:sage [04/10/22 11:02:18] >>754=>>733様 756 名前：753 mailto:sage [04/10/22 12:41:35] ぐあっ・・・ほんとだ　orz 駄ﾚｽでした。重複ｽﾏｿ 757 名前：デフォルトの名無しさん mailto:sage [04/10/22 14:05:19] >>732 >だまされたと思って一回原典読んでみてください。お願いします。 オマエが騙しそうだなー >>742 ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL 読んでみたんだけどなー > 「SQLが分からないから使わない」 > >んじゃなくて > >「SQLにビジネスロジックを入れたくないから使わない」 > >んです。 リッチなSQLの例が、SQLの入門書レベルだからなー 勉強したくないだけだろうと思われても仕方が無いなー VB厨でもPHPerでももっと複雑なSQLを普通に書くと思うなー >>752 そうだなー PoEAAが具体的にどういうシステムを想定しているのかを知りたくなるなー 758 名前：デフォルトの名無しさん mailto:sage [04/10/22 14:25:16] >>757 > リッチなSQLの例が、SQLの入門書レベルだからなー 同意 759 名前：デフォルトの名無しさん mailto:sage [04/10/22 15:02:33] SQLの中身については、いやまあサンプルって事で。 それいったら、過去実績である注文データに対して ディスカウントキャンペーンを適用するようなつくりになってて 蓄積された実績を何時でも恣意的に改変できる形になってるじゃん。 注文ってエンティティの構造は捉えられていても その意味というか本質というか、全然考慮されてない。 その理由は、勿論サンプルだから、でしょう。 まじボケだったらファウラー、おちゃめさんです。 つっこみ始めたらきりがないから、ここは 「SQLに業務ロジックを入れる」って事のだけ 見ればいいよ。 760 名前：デフォルトの名無しさん mailto:sage [04/10/22 15:42:20] >ただ、アプリケーション開発者はこれくらい複雑なだけでも避けちゃうんだよね。 これくらい↓ 複雑↓ SELECT DISTINCT MONTH(o.date) AS month FROM lineItems l INNER JOIN orders o ON l.orderID = o.orderID INNER JOIN customers c ON o.customerID = c.customerID WHERE (c.name = ?) AND (l.product = 'Talisker') GROUP BY o.orderID, o.date, c.NAME HAVING (SUM(l.cost) > 5000) 確かにおちゃめだ。Fowler氏自身はSQLを使いこなしているようだが。 このレベルを避けちゃうようなﾔｼと仕事してるのかと思ったら不憫に 感じるというか親近感が湧いたYO 761 名前：759 mailto:sage [04/10/22 15:54:39] 一人いたな、簡単なJOINのSQLでも 全部Accessで作ってからちょこちょこ直す人。 結構経験あって、Win32APIとかすごく詳しかったけど、 業務系はあまりやってこなかったみたい。 帳票のSQLとかほとんど俺が書いて、メールで渡してたなあ。 しかもその人がテーブル設計やったもんだからもう、 俺も不憫に思ってくれい。 そのSQL書ける人が書いてメールで渡すってのを メール経由でコピペとかじゃなくて、 きちんと組み込めるのがS2Daoな訳ですな。 762 名前：デフォルトの名無しさん mailto:sage [04/10/22 15:55:38] ・・・普通の集計にしか見えんのですが。 763 名前：デフォルトの名無しさん mailto:sage [04/10/22 16:11:53] その普通の集計をわざわざコードでやるがいいと おっしゃっておるのでつよ。 これがリッチSQLなのでつ。リッチクライアントも決して 普通のVBの画面にしか見えんのですが。 などといってはいかんのでつ。 764 名前：デフォルトの名無しさん mailto:sage [04/10/22 16:25:34] しょぼいSQLで済むことにあれだけコード書くようだと 複雑なクエリーが必要な場合にどれだけコードを書くんだ？ いくら将来性がどうとか言われてもバグが増えそうで俺は嫌だ あるかないかわからない移植のことを考えるよりもさっさと作って リリースするほうが重要なんじゃないか。いるものだけ作るという 原則に反している気がする 765 名前：デフォルトの名無しさん mailto:sage [04/10/22 16:39:18] つまりあれだ。 S2Daoﾏﾝｾｰってことだな。 766 名前：デフォルトの名無しさん mailto:sage [04/10/22 17:14:54] だな！ 767 名前：デフォルトの名無しさん mailto:sage [04/10/22 21:55:24] >>763 > リッチクライアントも決して > 普通のVBの画面にしか見えんのですが。 > などといってはいかんのでつ。 比較対象がHTMLフォームだから。 768 名前：デフォルトの名無しさん mailto:sage [04/10/22 21:58:01] あのドキュメントは社員さんが書いたのか。 サイトの運営も社員さんにやってもらったほうがいいね。 なんにしろ、組織的なサポートは心強い。 769 名前：デフォルトの名無しさん mailto:sage [04/10/22 23:55:07] >ビジネスロジックとは 意味わかんね。 だれかかいつまんで説明して 770 名前：デフォルトの名無しさん [04/10/23 00:39:25] >>764 問題は移植性だけじゃない。Fowler氏はいろいろ挙げてるじゃないか。 とくに問題になる点は ・更新性「EAはこれからめちゃくちゃ変わる」 ・カプセル化「ビジネスロジックを担当するコードがデータベース設計変更時に影響を与えられることはない」 だろう。 まあ、俺はどっちかというとS2Daoマンセー派だが、物事はそう単純ではないと言うことだ。 771 名前：デフォルトの名無しさん mailto:sage [04/10/23 00:50:40] 結局規模が違えば考え方も違うってことだね。 もちろん、SQLではなくてアプリケーション側で処理してもパフォーマンスに何ら問題ないようになると違うんだろうけど。 772 名前：デフォルトの名無しさん mailto:sage [04/10/23 00:57:52] >>770 EAはむちゃくちゃ変わるってのは 日本で業務系に携わってても 正直そこまで実感が湧いてこないんですが それは私の経験不足と言う事でさておいて 大体リッチなSQLを使う所って、経営分析データだとか 会計帳票とかになりますよね。 そういう所はEAとかいう部分と関係なくて 逆に安定しまくっとる所なわけで、 そこにSQL一発ですむものを複雑なコーディングに 置き換えるのはやはり気がひけます。 やっぱりいいとこどりが一番って事でしょう。 議論としちゃつまらん結論ですけどのう。 773 名前：デフォルトの名無しさん mailto:sage [04/10/23 01:35:27] 全体を捉えた議論の結論としては 「やるべきことをやる、使うべきところで使うべきものを使う」 ということになると思うが、じゃあ、どれはどこで使うのか？という議論が大事なんじゃないの？ つまり、その手法のメリットデメリットはなにか、と。 マンセーするにしても、いっさいがっさいそれでいくわけじゃなくて、多少のデメリットは目をつぶるという程度だろ？ 774 名前：デフォルトの名無しさん [04/10/23 02:33:35] 　　殺伐としたスレに救世主が！！ 　　　　　　　無職 　　 　 　 ヽ|・∀・|ノ 　＜人殺しマン参上 　　　　　　 |=◎=| 　　　 　 　 　|　| headlines.yahoo.co.jp/hl?a=20041022-00000505-yom-soci 775 名前：デフォルトの名無しさん mailto:age [04/10/23 03:05:17] S2JSF間近aga!!! 776 名前：デフォルトの名無しさん mailto:sage [04/10/23 03:07:08] >>770 > ・更新性「EAはこれからめちゃくちゃ変わる」 だったら今考えている柔軟性が通用するかどうかわからんように思うのだがどうか？ > ・カプセル化「ビジネスロジックを担当するコードがデータベース設計変更時に影響を与えられることはない」 データベース設計が変わったらそれを使っているビジネスロジックも変更する必要があると思うのだがどうか？ 云わんとしていることはわかる気がするんだが冗長過ぎる気がしてならんのだよ。 777 名前：デフォルトの名無しさん mailto:sage [04/10/23 03:51:27] ファウラーのblikiを翻訳してる方によると やはり日本とアメリカの事情の違いってのがあるそうで、 日本にくらべてあっちはアプリ開発とDB開発の分業が 相当徹底されているらしいですね。 で、 > ・カプセル化「ビジネスロジックを担当するコードが >データベース設計変更時に影響を与えられることはない」 ってのは、776の言う通り、設計変更っていや ビジネスロジックの変更の事だろう、って気分に私もなりましたが もしかしたらアメリカさんの事情ならではの発想なのかも知れないなあ と思った訳です。向こうからしたらこっちの言ってる事がドンくさいと思われるかも。 あくまでも推測なんで、アメリカさんの事情に詳しい方いらっしゃいましたら うそつけバーカとか書いちゃって下さい。 あと、私も含めてですが776の「DB設計変更=ビジネスロジックの変更」って考え方は、 やっぱり前提がDOAなんでしょうねぇ。でもしっくりくるよね、皮膚感覚で。 778 名前：デフォルトの名無しさん mailto:sage [04/10/23 04:00:15] 773の意見にまったく同意です。 でもまあ、総論みたいな所も、答えは「いいとこどり」に 落ち着く事は判っていても、喧々諤々やっといた方が いいと思うんですよ。 その事で、双方の「いいとこ」の範囲が、 前より広く感じられて来たりしたら良いと思うし。 ここ、読んでて大変面白いですよあたしゃ。 2ちゃんのOO関連スレじゃ一番じゃないですか？ 779 名前：デフォルトの名無しさん mailto:sage [04/10/23 04:13:28] 関係ないが、某blogでマジックナンバーはいいの悪いの、っていうのがあって、アクセッサ作れってあるけど、すべての定数についてアクセッサ作らされてたらたまらんな、と思った。 結局、マジックナンバーを使うなってことではなくて業務数値をその数値を保持するべきではないところに置くな、ってことじゃないのかな。 780 名前：デフォルトの名無しさん mailto:sage [04/10/23 04:49:47] 言語とRDBMSと、どちらが変更される可能性が高いか。 どちらとも言えんと思う。 言語が変わる場合： C/S からWEB系への移行 Unixに乗り換えで、ASPからJavaへ移行 RDBMSが変わる場合： パッケージもの。お客様によってRDBMSが異なる 辺縁系のシステムなら、Oracleなどからオープンソースに乗り換え。 他にどんな場合があるかな？ 781 名前：デフォルトの名無しさん mailto:sage [04/10/23 05:18:03] 言語は変わる場合より併用の方が多いんじゃないかな。 たとえば、メール処理をするのに、VM起動を嫌ってPerlのスクリプトでやるとか # 実際はサーブレット呼び出すようにしてJavaで処理させたりするが。James？なにそれ。ｗ 部分的にPHPで組むことも考えられる。 RDBMSで言えば、最初はPostgreSQLで運営してたけどサービスが成長したからOracleに移行とか。 Windows上のSQLServerで運用していたけど、大人の事情でUNIX使うことになって、Oracleへ、とか。 PostgreSQL→Oracleのようなスケールアップはありがちなんじゃないかと。 逆に、移行しやすいように作っておくことを前提に当初はPostgreSQLで運用開始とか。 782 名前：デフォルトの名無しさん [04/10/23 09:23:30] >>781 > たとえば、メール処理をするのに、VM起動を嫌ってPerlのスクリプトでやるとか いろんな言語を組み合わせるのはどうにも気持ち悪い。メンテナンスしづらいでしょ。 開発環境そろえるのに時間かかりそう。環境によってあーだこーだ言うのは最悪。 バージョンがこうだとか、ディレクトリ構成がこうだとか。ウザい。 シンプルが一番。 アプリケーション毎に常駐プログラム作ってそこでデータベースなりメールの処理するとかするでしょ普通。 ポータビリティが重要だと思う。 CVSのモジュールを引っ張り出すだけで自前の環境でシステムの自動テストができるような単純さが開発では重要。 加えると、Javaって面倒だ。 全部スクリプトで作ってしまえばいいと思うのだが。 783 名前：デフォルトの名無しさん mailto:sage [04/10/23 11:13:19] >>777 だからコミュニケーションの重要性が 日本以上に言われるのかな＞分業の徹底 784 名前：デフォルトの名無しさん mailto:sage [04/10/23 11:40:46] >>783 うん、そうみたいですね。 blikiの翻訳者さん、こんなのも翻訳してまして tp://capsctrl.que.jp/kdmsnr/wiki/agiledata/ ここみると、「なぜ一緒に働くことが現在困難なのか」とか なんかアプリ屋とDB屋がまるでイスラエルとパレスチナの様で、 日米の文化の違いはかなりのもんの様です。 でもアメリカさんだから、ジョークというか 比喩かも知れないですけどね。 785 名前：デフォルトの名無しさん mailto:sage [04/10/23 11:47:58] seasarの良いところがいまいち分からんなー。 インターフェース書いて、ダイコンファイル書いて ってめんどくせーって思っちゃう。 サービスに新しい機能付けようと思ったら、インターフェース とImplクラスの２つを変更しなきゃいけないし。 インターフェースはImpl挿げ替えるだけで、動きを変えられるって メリット（多態性）で使うんであれば良いし、よく使うんだけど seasarのためにインターフェースガンガン書くって気にはどうも慣れん。 ダイコンファイルでImpl差し替えるって事ってそんなにたくさんあるのかな。 漏れはstruts+Hibernateで全然作ってるけど、「それだとここめんどくさくない？ なので私はseasar使うようになったよ」って意見を聞きたいです。 あとEJBはseasarよりさらにダルイっておもっとる。 786 名前：デフォルトの名無しさん mailto:sage [04/10/23 11:59:55] 別に無理してまでインターフェース用意することも無いでしょう。 必要に迫られたときにインターフェースを抽出することは IDEなんかのツール使えば一瞬で出来るんだし。 787 名前：786 mailto:sage [04/10/23 12:01:40] ただ、インターフェース使うとimplのすげかえ以外にもメリットが多いのは事実です。 不必要なメソッド呼び出しを隠蔽できたり、Mock使ったテストが容易になったり。 788 名前：785 mailto:sage [04/10/23 12:21:54] レスありがとう。 >別に無理してまでインターフェース用意することも無いでしょう。 seasarってインターフェース必須ではないんだー。誤解してました。 >不必要なメソッド呼び出しを隠蔽できたり、 これは、漏れのやる仕事のに依存してるのかもしれないけど APIのようなクラスを作るときは、隠蔽って重要だと思います。 でも、そうではない業務ロジックの実装だと余り隠蔽したい場合に 出くわさないんですね。 >Mock使ったテストが容易になったり。 これはもう少し詳しく聞きたいです。seasarのドキュメントにも テストが容易って書いてありますが、EJBに比べてって事ですか？ struts+Hibernateでテストしにくいって感じた事無いんですよね。 789 名前：デフォルトの名無しさん mailto:sage [04/10/23 12:28:07] >>785 seasarというより、インターフェースと実装を分離するということは、 OOの重要な部分だと思うけど、分業するときに、 インターフェースを先に決めておけば、実装が追いつかなくても、 Mockとかを使って作業を並行して進められるというメリットがあるね。 実装クラス同士が直接依存しあうことが少なくなるから、 個々のクラスの個々のメソッドを単独で実装・テストしやすい。 直接依存してると、依存しあっている部分を全部コーディングしないと テストできないから。 790 名前：デフォルトの名無しさん mailto:sage [04/10/23 12:32:00] >>788 ふだん、どんなテストしてるの。 791 名前：785 mailto:sage [04/10/23 13:10:24] >>789 >Mockとかを使って作業を並行して進められるというメリットがあるね。 でもインターフェースじゃなくて、空のクラスだけMockとして用意するのも 同じだと思うんですが。あ、もちろんどちらが綺麗かって言われたら インターフェースがある方ですが。。。 >依存しあっている部分を全部コーディングしないと >テストできないから。 うーんseasarもダミーの実装をダイコンファイルに書いてるだけ なんだよなと。Implクラスにダミーの戻り値を書いておく方が 楽と感じてます。 >>790 普段は下層のDAOから実装していくって感じなんで （階層での作業分担はしない）、DAOの単体テスト=>サービスの単体テストって感じ。 サービスで他のコンポーネントに依存するようなら、まずそっちから実装かな。 相互に依存する場合は、必要になるメソッドだけOr上で書いたダミーの実装。 他の人のコンポーネントが必要なときは、クラスだけもらってダミーの実装だなー。 792 名前：デフォルトの名無しさん mailto:sage [04/10/23 13:34:02] >>791 それなら、それでいいんじゃないですか。 うまくいってるなら、特に変える必要はないと思います。 でも、ダミーの実装を作って、取り替えてなんて、 やるのは、大変そうですけどね。 あとから、実装が何だかおかしいから、ダミーに戻して 確認するってのも大変。 ちゃんとバージョン管理しているなら、ダミーと実装の 管理がすごく複雑になる気がします。 793 名前：デフォルトの名無しさん mailto:sage [04/10/23 13:57:33] まさか、自動テストの一括実行をやってないとか。 794 名前：785 mailto:sage [04/10/23 14:32:12] >>792 ダミーの実装はバージョン管理に追加しないですね。 中身の無いクラスだけコミットしてもらって、ダミーの 実装は各自勝手にといった感じ。中身が出来たら更新。 その点seasarはダイコンファイルで複数のダミーパタンを用意して それを取っておけるのが良いですね。 >あとから、実装が何だかおかしいから、ダミーに戻して >確認するってのも大変。 実装が出来上がっちゃったら、ダミーに戻すことは無いですね。 おかしいなって思ったら、大抵他人のコードでもデバック しちゃいます（修正はしないで、原因だけ伝えるかな）。 上の方で言ってるくーすの話は面白いですね。seasar大して使ってないけど 設計論なんで、関係ないし。 ただ、貧血症とか、DAOにビジネスロジックとかって答えがあれば聞きたいけど 答えなんかないんだよね。漏れ的には、迷ったらメンバーで相談する。 SQLでやった方が楽で、早いならSQLでゴリゴリって書いて、ドキュメントなり 分かる形で残す。ViewとDAOのデータの受け渡しはBeanUtilsマンセー。 795 名前：デフォルトの名無しさん mailto:sage [04/10/23 14:38:34] >自動テストの一括実行をやってないとか。 それってseasarと関係なくない？ seasar使ってないとJUnitで一括実行出来ないとでも？ 796 名前：デフォルトの名無しさん mailto:sage [04/10/23 16:59:16] デバックってゆうな〜 797 名前：デフォルトの名無しさん mailto:sage [04/10/23 18:00:15] >おかしいなって思ったら、大抵他人のコードでもデバック 切り分けにはモックを使う方が便利。モックの造りにもよるけど。 モックは単純実装になってるはずなんで、モックが仕様通りなら 他人のところがおかしい可能性大。 モックが間違っているならモックを直して再テスト。 ちなみにdebugなんでデバッ"グ" 798 名前：デフォルトの名無しさん mailto:sage [04/10/23 18:24:12] OSSに対する直接的な貢献というのは、狭義にはソースコードの提供である。 通常は元となるソースに対しての差分をパッチという形で提供することになる。 そのパッチをメンテナと呼ばれるコアな開発者にメールなどで送りつける事が狭義の貢献である。 メンテナはそのパッチをみてよければ採用しよくなければ採用しない。 良い悪いというのはどうやって判断するのか？オープンソースの七不思議である。 ある人のパッチは受け入れられてある人のパッチは受け入れられない。 ある種の経験則はもちろんあるがその経験則を厳密に記述する事は難しい。 商用ソフトウェアの場合はコードの変更は担当者が行うので受け入れるも受け入れないもなくて 各社の社内規約に従って淡々とコードが追加されていく。 オープンソースの場合その明文化された「社内規約」に相当するものがないので、 ある種の秘密クラブの掟みたいな空気によって様々な意志決定がなされる。 新参者は空気を読め、空気をという話である。 799 名前：785 mailto:sage [04/10/23 18:58:14] デバッグですね。お恥ずかしい。。。 >切り分けにはモックを使う方が便利。 これは同意です。ただ、相応の手間が漏れには受け入れられないなと。 逆に他人のコードをデバッグして得られる事も多いです。 ただ、開発フェース外での他人のコードをデバッグするような事は 勘弁ですが（ｱﾊ　 800 名前：デフォルトの名無しさん mailto:sage [04/10/23 19:10:45] >>798 何のコピペ？ 801 名前：デフォルトの名無しさん mailto:sage [04/10/23 19:36:39] はぶ氏もひが氏もここの話題に反応してくれてますな っと、話ふり逃げに思われると残念なので書いとこう 802 名前：デフォルトの名無しさん mailto:sage [04/10/23 21:45:01] >>800 これだろうな。 ttp://d.hatena.ne.jp/hyoshiok/20041022

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef