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/
666 名前:デフォルトの名無しさん mailto:sage [04/10/18 19:18:17] 今の流れって前向きなの?ム板ですべき話なのかな? 技術のギの字も出さずにただ現場の話がしたいだけなら マ板いけば? って、所詮2chかw
667 名前:デフォルトの名無しさん mailto:sage [04/10/18 19:34:01] 俺はそんなにスレ・板違いにも思えないんだな。 S2からくーすにつながる中で やっぱり現場の話は、どうしても出るよ。 それだけ実践的なものって事なんでしょう。 ムだのマだのでがっつり分けたがる方が 所詮2ch。
668 名前:デフォルトの名無しさん mailto:sage [04/10/18 20:02:15] >>666 前向きもうしろ向きもなく、雑談。
669 名前:デフォルトの名無しさん mailto:sage [04/10/18 20:03:18] マ板は、ネタスレ用隔離板ですよ。
670 名前:デフォルトの名無しさん mailto:sage [04/10/18 20:04:47] 現場の話が技術の話だと思わないあなたはピープルウェアでも読んでください。
671 名前:デフォルトの名無しさん mailto:sage [04/10/18 22:29:15] スルーしる
672 名前:デフォルトの名無しさん mailto:sage [04/10/18 22:45:41] そんなことよりも S2JSF だよ。 まだでねーのかよ! S2Flex とかどーでもいいからはやく S2JSF リリースして栗
673 名前:デフォルトの名無しさん mailto:sage [04/10/18 23:39:08] OpenSymphony QuartzのJobにDIしたいと考えてるんだけど、タイミングが つかめない。Jobインスタンスは実行ごとに生成されてそうだから、JobRunShell でnewInstance()するごとにDIせねばならん。 Tapestryもそうだけど、元のライブラリがDIを考慮した設計になってないと きついな。
674 名前:デフォルトの名無しさん mailto:sage [04/10/19 02:32:25] はぶさんも、いちいち相手にしなけりゃいいのに。 「伝染るんです」のスズメみたいなもんなのにね。
675 名前:デフォルトの名無しさん mailto:sage [04/10/19 03:31:31] おお、すずめかあ。懐かしいなあ。 でもピンポンダッシュっぽい感じもするので 「こらー!」ってゆってくれないとちょっと寂しい。
676 名前:デフォルトの名無しさん mailto:sage [04/10/19 03:50:38] いやー、言いたいことをおもしろおかしく、語弊と誤解とあらぬ疑いをまじえながら、勝手に書き込んでるだけなんだよね。 2chってところは。 で、怒られたら逃げる。でもやっぱり離れたところでこそこそやる。 怒られなかったらそれはそれでちょっと寂しい。
677 名前:デフォルトの名無しさん mailto:sage [04/10/19 13:18:16] >673 そうだね。一応outer定義してinjectDependencyという手段はあるけど、 メリットのあらかたを享受できないからね。 DIを考慮した設計でなくてもいいけど、生成部分の自由度が低いと辛い。
678 名前:デフォルトの名無しさん [04/10/19 20:57:03] 業務アプリケーションをそんなに急いで作りたいなら、一番確実な方法としては 「あらかじめ作る」しか無い。 つまり、業務アプリでEclipseみたいにプラグインで拡張可能なソフトを作ることだと思うよ。 (この設計は極めて難しいものになるだろうけど。)
679 名前:デフォルトの名無しさん [04/10/19 20:59:44] 業務アプリとはいえ、プラグインプログラミングをやらうとするなら、 ソース公開されていることは必須条件。別にGPLじゃなきゃだめというわけじゃないけど。 (ソース読まずにプラグインだけ作ることは無理だ)
680 名前:デフォルトの名無しさん mailto:sage [04/10/19 21:23:49] >>678 StrutsやらHibernateやらいろいろ抽象化してくれるものと、DI+AOPのおかげで、極めて難しいというほどではないとおもう。 規模やら分野によるだろうけど。
681 名前:デフォルトの名無しさん mailto:sage [04/10/19 23:15:00] この中の何人くらいがちょっとS2さわってみたとかではなく、 実案件でS2を適用し、かつ無事にリリースできているのでしょうか?
682 名前:デフォルトの名無しさん mailto:sage [04/10/19 23:31:44] 3.14人くらい?
683 名前:デフォルトの名無しさん mailto:sage [04/10/20 00:10:39] S2というか、そもそもJavaで実装すること自体やめたほうがいい
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()欲しい。 所詮2chなんで、さらっと無視して下さい。 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] 何かに依存した設計のデメリットを、ロッドジョンソンに身を以て教えられた。 そんな27歳の秋。
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の発展的なアプローチだろうと思います。 ひがさんは否定しておられるようですが、サービス層と永続化層を分離した パターンの中で、大別して上記2つ以外に思いつくものはありません。 というか何がどう違うのかもうちょっと説明して欲しいかも。 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は部品化以外の用途で仕事で使うには、頭がよい人を期待しすぎだよ。 自分で設計してるときはそりゃ楽しいけど、実働後の保守メンバーに馬鹿が1人いただけで設計が崩壊しかねない。 それが自分だったりして鬱になる。 例えると、天才が設計したゼロ戦で華麗に舞って死ぬよりも、 芸が無いグラマンでデスマから生還したほうがいい。
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] だな!