国産オープンソース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/ 684 名前：デフォルトの名無しさん mailto:sage [04/10/20 01:06:05] なんで？ 685 名前：デフォルトの名無しさん mailto:sage [04/10/20 01:27:24] Jobの抽象クラスを作って、実行前にSingletonS2ContainerFactory.getContainer() を呼ぶか。 686 名前：デフォルトの名無しさん mailto:sage [04/10/20 01:29:31] S2コミュニティって、コアのおっさんたちは確信犯だろうから別にいいんだが、 周辺の若手マンセー君たちがイタイ。 何で「くーす=現場密着使える」「それ以外のOO方法論=机上空論使えねー」 って2分割の構図で思考停止できちゃうのかわからん。 # 逆説的に、2年前くらい前に「Togetherでラウンドトリップ」とか「永続化は # EJB2.0CMPで決まり」とか「Struts最高」とか「Taglib凄い」とか言って # 懐疑派を時代遅れの馬鹿扱いしてたやつらと同じ罠にはまってる気がする。 くーすは、素人だらけの現場でいかに一定の品質をキープするかという点 (予測可能性?)にフォーカスした、いわば極めて後ろ向きな方法論であって、 決して根本的な工数の削減やメンテナビリティにはフォーカスしていないと思う。 Transaction Scriptの欠点は単価安い下っ端ブルートフォース(+中国?)で カバー、的な。 687 名前：デフォルトの名無しさん mailto:sage [04/10/20 01:41:00] スレの流れとは関係ないが、なぜか同じ穴のムジナという言葉を思い出しちゃったな。 688 名前：デフォルトの名無しさん mailto:sage [04/10/20 02:04:06] S2Daoに要望 ・挿入時にAuto Incrementフィールドを オブジェクトのプロパティで更新しないようにしてほしい。 ・数値とbooleanの変換をして欲しい。 ・countXXX(), sumXXX()なんかの集計関数の自動生成が欲しい。 ・テーブル名、エイリアス名は`なんかで囲って欲しい。 ・getLastInsertId()欲しい。 所詮２chなんで、さらっと無視して下さい。 S2JSF期待してます。 どうぞご自愛ください。 689 名前：デフォルトの名無しさん mailto:sage [04/10/20 06:33:55] >「それ以外のOO方法論=机上空論使えねー」 ってあったっけ？ 誰が若手やらわからんので俺が見てないだけかもしれんが。 690 名前：デフォルトの名無しさん mailto:sage [04/10/20 06:39:58] >>686 TransactionScriptが ロジックの共有化をはかると構造が複雑になる と述べている理由を述べよ。 なんか、大きい仕事を任せてもらいない人が 思い込みで語っているような。 あなたにまかされたプロジェクトが、いかに効率的 なのか説明してみよ。 691 名前：デフォルトの名無しさん mailto:sage [04/10/20 09:19:09] S2Quartz!!! d.hatena.ne.jp/khi/20041020 692 名前：太田＠会社 mailto:oota_ken@hotmail.com [04/10/20 12:05:09] 686さん> 「若手マンセー君」はWithout EJBの勉強会に参加して見回した限りは (本当はRUP推進派の)僕も含めて存在しないです。僕自身の立場としては 限られたりソース内での最大限の効果を望む社内のDOA(Data Oriented Approach)な人にも使っていただけ，単体テストが効率化する「くーす」と Seasar2(および周辺プロダクト)を応援しているというだけで，マンセー ってわけではないです。理想は，でも現実的には，だったらどうしたらよい という前向きな人たちの集まりだと思うのだけど。そうじゃなかったら休日の 半日つぶして勉強会に集まったりしませんよ。 693 名前：デフォルトの名無しさん mailto:sage [04/10/20 13:08:35] >>686 >2分割の構図で思考停止できちゃうのかわからん。 思考停止しているのは、あ・な・た☆ 694 名前：デフォルトの名無しさん mailto:sage [04/10/20 19:20:59] 比嘉氏・取り巻き・羽生氏ときて今度は若手か。 徹底的に人に絡んでくるな。 695 名前：デフォルトの名無しさん mailto:sage [04/10/20 19:25:28] つうか、取り巻きって誰かが明示されてないし。 イタい取り巻きの例示きぼん>>686 696 名前：デフォルトの名無しさん mailto:sage [04/10/20 19:26:14] s/取り巻き/若手 697 名前：デフォルトの名無しさん mailto:sage [04/10/20 19:34:42] んなこといいけど、S2JSFって進んでるのかな？ なんか、S2FlexとかS2.1とかくーす本とかで忙しいみたいだからねえ。 S2JSFのためにS2のバージョンアップが必要なのだろうか？ 698 名前：デフォルトの名無しさん mailto:sage [04/10/20 19:48:08] S2JSFのためのS2.1化だろ。 699 名前：697 mailto:sage [04/10/20 19:49:30] う〜〜待ちきれない 700 名前：デフォルトの名無しさん mailto:sage [04/10/20 20:04:00] そこでJSF-Springですよ 701 名前：デフォルトの名無しさん mailto:sage [04/10/20 20:30:58] >>695 やめれ。これ以上個人名を出す必要はないよ。 比嘉氏や羽生氏はともかく他の人は関係ない。 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屋がまるでイスラエルとパレスチナの様で、 日米の文化の違いはかなりのもんの様です。 でもアメリカさんだから、ジョークというか 比喩かも知れないですけどね。

---

---

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

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