国産オープンソース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/ 528 名前：デフォルトの名無しさん mailto:sage [04/10/10 23:11:40] >>520 フレームワーク外の作りこみ一切禁止なんて縛りがあるわけでもないのに、 なぜそこで完璧を目指す必要があるのか理解できない。 パレート原則で言う8割の側を押さえるだけで十分では? 529 名前：デフォルトの名無しさん mailto:sage [04/10/10 23:23:01] しってる難しそうな言葉をならべて賢くなった気になる遊びですた。 530 名前：デフォルトの名無しさん mailto:sage [04/10/10 23:53:24] >>529 理解できない会話に無理に加わる必要はないよ、坊や。 531 名前：デフォルトの名無しさん mailto:sage [04/10/10 23:56:29] 2chだな〜 532 名前：デフォルトの名無しさん mailto:sage [04/10/11 01:57:15] >>527 > 負荷分散やらクラスタリングなんかDIコンテナで解決する問題じゃないし。 だってDIコンテナの作者らがEJBｲﾗﾈって言ってんだもん。 533 名前：デフォルトの名無しさん [04/10/11 02:28:34] J2EEを使った業務システムで、そこまで必要なシステムって多くないし その程度のシステムでEJBはイラナイだろ。 534 名前：デフォルトの名無しさん mailto:sage [04/10/11 03:05:48] >532 DIコンテナの長所挙げるとき散々*EJB*と比較して、 難しいとか、テストが大変とかEJBの短点ばかり挙げるのにな（ｗ 535 名前：デフォルトの名無しさん [04/10/11 04:37:42] 遡ると、なぜJavaを選択するのかという話にならないか 短いコードで表現力の高いプラットフォームなら他にあるだろうに 536 名前：デフォルトの名無しさん mailto:sage [04/10/11 07:14:54] >>532 負荷分散やクラスタリングは、ロードバランサや HttpSessionでやった方が良い。 EJBでやるよりよっぽど実績がある。 537 名前：デフォルトの名無しさん [04/10/11 07:38:11] >>536 HTTPって、それは単にウェブサーバの負荷を分散ではなかろうか。 素人なんだけど、業務アプリの場合、データベースのバックアップも兼ねた クラスタリングが重要になるのでは？ 538 名前：デフォルトの名無しさん mailto:sage [04/10/11 08:13:38] >>537 C-JDBC使えば？ 539 名前：デフォルトの名無しさん mailto:sage [04/10/11 08:24:57] >>537 業務ロジックは、Servletコンテナと同一VMで動かすのが パフォーマンス的には良い。 スケーラビリティがなんて言うやついるけど、 業務ロジックよりもWebの部分が先にボトルネックになる ケースの方が多い。 データベースへの接続も負荷分散装置使えるよ。 EJBコンテナで負荷分散やクラスタリングしているシステムなんて ほとんど見たことないけど。 540 名前：デフォルトの名無しさん [04/10/11 09:05:44] >>539 いや、しかし、世間的にはどうか知らんが、 漏れの経験では業務アプリでウェブベースなほうがむしろ稀だった。 ウェブベースなのは補助的な用途の場合が多い。 そういうときって、やはりクラスタ機能ある常駐プログラム 作る必要あるわけで、それはJavaで作るならばejbかdiコンテナか選択するんだろうな。 業務アプリに必要なのって、サービスを管理するライブラリだよね。 インストールはコマンド一発。 DHCPでIP振られたら自動的にデータベース起動して、アプリサーバ起動して、 クライアント探して・・・　っていうのを自動でできるようにしなきゃいけない。 （でないと導入コスト高いんだ） 541 名前：デフォルトの名無しさん mailto:sage [04/10/11 09:37:23] >>540 S2の用途は539の言うとおりだと思う。 S2が自分の用途に向かないなら他を探すのが良いと思う。 542 名前：デフォルトの名無しさん mailto:sage [04/10/11 10:28:32] 今のトレンドはStatelessだよな。EJBを使うにしてもだよ。 ということは負荷分散をEJBコンテナがやらなければならない ケースは少ないといえるんじゃないのか。しかもHTTPだろ。 俺ならロードバランサを前に挟むけどな。 543 名前：デフォルトの名無しさん mailto:sage [04/10/11 10:30:16] >>537 そういう場合は、DBの機能を使うよ普通。 OracleならRACとかな。EJB使うほうが当てにならん。 544 名前：デフォルトの名無しさん mailto:sage [04/10/11 10:38:24] >>532 実際要らないシステムが多いだろ。デプロイが楽だからWeb使うだけで 大したトランザクション量じゃないシステムも多いよ。 >>534 そりゃそうだろ。DI自体がEJBに対するアンチテーゼだからな。 インコンテナのテストなんて面倒だろうに。 当のEJBだってPOJOに方向転換じゃないか。 EJB*だけ*がスケーラビリティ確保の手段だと本当に思ってるのか？ PHPで大規模やってる連中だっているだろ。そいつらが どうやって負荷分散やフェールオーバを実現しているのかを見れば EJBのレイヤーでなくてもやれることがいっぱいあるのはわかるだろ。 頭が固いか不勉強か単なる言いがかりかのどれかに見えちゃうぞ。 545 名前：デフォルトの名無しさん mailto:sage [04/10/11 10:49:08] >>534 EJBの長所が負荷分散だというなら それはEJBでなくても他に汎用的で 実績のある代替手段を使えばそれで 済むんだからEJBｲﾗﾈってことになるな。 EJBのテストが面倒なのは事実。 性能が出なくて変なテクニックばかり 横行するO/RマッピングもHibernateや S2Daoのほうが便利で性能がいい。 EJB-QLなんて何の意味がある？ EJBの長所は何があるんだ？ DIがなくてもEJBにはウンザリしてるよ。 546 名前：デフォルトの名無しさん mailto:sage [04/10/11 10:50:42] EJB擁護派はこちらで論破してきてください。 EJBは終わってる pc5.2ch.net/test/read.cgi/tech/1036481443/l50 547 名前：デフォルトの名無しさん mailto:sage [04/10/11 12:42:54] >>537 フェールオーバとロードバランスは別だよ。 でもってどっちもDIとかEJBとか関係なく 考えるべきものだから。クラスタリングは EJBの専売特許ではない。 548 名前：デフォルトの名無しさん mailto:sage [04/10/11 13:41:47] >540 「DIコンテナ」部分だけ使うなら、他を自作しても邪魔にはならないよ。 S2開発者が主軸に考えてるのがWebだってだけ。 周辺プロダクトはそれに合ったものからでてくるけど、別に必須ってわけじゃない。 業務機能と非業務機能を全部自作するにしても、DIコンテナで管理できると楽だ。 549 名前：デフォルトの名無しさん mailto:sage [04/10/11 14:05:45] >>540 なんか、もっとすっきりできる気がするが・・・ 550 名前：デフォルトの名無しさん mailto:sage [04/10/11 14:52:49] diconファイルはシンプルだけど、それでもいろいろ書き間違える。 Kijimunaがないとやってられない。 Kijimunaってどれくらい使われてるんだろう。 SpringIDE(?)と比べるとどう? 551 名前：デフォルトの名無しさん mailto:sage [04/10/11 15:02:57] >>550 「どれくらい使われているか」より「どれくらい使いやすいか」の方が大事 552 名前：デフォルトの名無しさん mailto:sage [04/10/11 15:22:36] >>551 最新バージョンは使いやすいよ。 何が自動インジェクションされているかも分かるし、 コンポーネントの定義からソースにも飛べる。 553 名前：デフォルトの名無しさん [04/10/12 01:45:36] Strutsでページ遷移の単体テストにS2Struts使うと楽になりますかねぇ？ 554 名前：デフォルトの名無しさん mailto:sage [04/10/12 07:30:29] >>553 なるよ。 555 名前：デフォルトの名無しさん mailto:sage [04/10/12 21:58:53] JBossで座絶したんだけどこれ結構使える？ 556 名前：デフォルトの名無しさん mailto:sage [04/10/12 22:14:53] ちょっとずつ始めれるので、挫折しにくいよ。 557 名前：デフォルトの名無しさん mailto:sage [04/10/13 00:04:53] 何に挫折したのかを書くと世話焼きが相手をしてくれるぞ Servletで挫折したならそれはJBossのせいじゃないからな。 558 名前：デフォルトの名無しさん mailto:sage [04/10/13 02:59:31] インストールで挫折しますた。 559 名前：デフォルトの名無しさん mailto:sage [04/10/13 03:04:47] ダウンロードに挫折しますた。 560 名前：デフォルトの名無しさん mailto:sage [04/10/13 10:51:27] はぶにっき、訳分からん。突然切れチョル。 日記だからっちゅうても、雑誌に「S2はblog駆動」とか書いてるん だから、何について言ってるんかハッキリするか、非公開にするか せんと。 自分、さんざん内向きにアピールしちょるやないけ。 ひが氏が２chの戯言にまで耳を貸して、開発やドキュメント整備に 尽力しとるのを、足ひっぱっとりゃせんか？ 車やコンピュータや家電だけが産業と違うじゃろ。 ハードウェア屋がコスト削る部分なんざ、ソフトでいえばコンパイル部分よ。 ここがこれ以上ないぐらい最適化されとるんやし、全品オーダーメイド で、掛かる費用ほぼ人件費な状態を、車と一緒に考えられんわい。 「客に向け」「この業界に先はない」っちゅうんは至極まっとうだと思うが。 ttp://d.hatena.ne.jp/habuakihiro/ 561 名前：デフォルトの名無しさん mailto:sage [04/10/13 10:53:23] メインフレーム時代からコストどれだけ下がったか。 562 名前：デフォルトの名無しさん [04/10/13 10:59:26] >>560 あれは基本的に経営側の人間であって開発側の人間ではないのよ。 だから、経営の視点で開発の人間を判断して、当人としては歯がゆい思いを感じているんだろう。 といって、偉そうなこと言う割にはべつに経営で成功しているわけではないあたり、 文句たれている相手と同じ程度の人間であることをさらしてしまってるのだが、 それに気付いていない無知の無知がちょっとイタい。 563 名前：デフォルトの名無しさん mailto:sage [04/10/13 11:16:17] >> 562 人格はどうでもいい。 564 名前：デフォルトの名無しさん mailto:sage [04/10/13 11:27:28] つうか、はぶ氏個人の評価はスレ違い。 565 名前：デフォルトの名無しさん mailto:sage [04/10/13 11:40:43] 「経営側に回れるだけレベルは上」と考えてるんだろう、ある意味間違ってないが 566 名前：デフォルトの名無しさん mailto:sage [04/10/13 12:00:24] >>560 capsctrl.que.jp/kdmsnr/diary/20041012.html#p05 ここへのコメントの続きじゃないの？ ここの人、若いんだけど、いっつも歯に衣着せぬ物言いなんで （あ、若いからか）、いっつも微笑ましく読んでたんだけど さすがはぶたんですなー、容赦せんもん。 上記サイトの人、今会計の仕訳の勉強とかしてるみたいで、 そういう勉強中の人に「DOAなんて否定的な表現」うんぬん言われると、 むちゃくちゃ厚い債権債務帳票とか出したり、 やったらきっつくて頭の切れる、出禁とかすぐ口に出すお客さんと 仕事した事あるのかなあ、と思ってたので、 ちょっとだけ溜飲が下がったよ。 はぶたん徹底して「顧客」って言わないね。お客様、と言う。 ちょっと気持ち悪くは感じたけど、プロなんだなとは思った。 567 名前：デフォルトの名無しさん mailto:sage [04/10/13 12:38:18] まあなんつーか、たまに余人に見えないモノが見えてるヒトではあらぁね、 ソレが天才だからなのかデムパ受信してるのかはむろん余人に分かろうハズは無く… ナニが言いたいかつーともーすこし他人の目を意識して書いてくださいと ＞金持ちに寄生して搾取してるだけじゃん。狭い世界の中で偉そうにしてるだけですよ。 ＞OOもDOAも構造化も全員そうだよ。コバンザメでしかないよ。世界中が腐ってる！ 568 名前：デフォルトの名無しさん mailto:sage [04/10/13 13:02:47] コメント化って空のコメントがあるだけなんだけど なんか書いてあったの？ 569 名前：デフォルトの名無しさん mailto:sage [04/10/13 13:14:31] 相変わらず個人ネタか。 570 名前：デフォルトの名無しさん mailto:sage [04/10/13 13:39:38] でも、お客にとっちゃOO分析だろうがER分析だろうが 知った事ではないだろうってのは、 くーすのよってたつ所なのではないかなあと思った。 だから本がどんなんなるか楽しみな訳で。 前に、見積もりの提示の仕方についても盛り込んでくれたらなーって ここに書いたんだけど、それも上記が理由。 571 名前：デフォルトの名無しさん mailto:sage [04/10/13 14:24:45] > 方法論がエンジニアにとって癒しにしかなってないじゃん、って思うんですよ。そりゃね、 > みんな賢いからさ、そういう人間が集まって膝突き合わしてそういうやり取りしてれば、 > 自分だけじゃない、って思えるしそりゃ楽しいでしょう。 > 別にS2でなければならない、ってこともないんですよ。EJBでも構わない。 > PHPでもRubyでもいいんですよ。 > 幾ら優れたことをやっても、根本的に「で？」としかならない。自分が一顧客として金を > 出すとしたら、って考えると、欲しいのはそんな裏方の話じゃないっしょ。 これまた正論だが、日記でよく言うね。だが、あんたが自分でも気づかないフリしてる 心境は 「確かに S2 は良いかもしれない。ひがが目立つのはうれしいが、俺のほうが できる人間なのにが影に隠れてるのはくやしい。」 だろ。 だいたい、客に伝わらんのはあんたの営業能力不足だろ w 古い言葉で言えば「バカの壁」だな。規模が違う話して悪いが、例えば IBM の研究所の 人間でもあんたは 「方法論ばかり言ってないで少しは経営のことを考えろ」 って言うか？ 類稀な経営手腕を持ってんだったら、開発者に対してやる気なくすこと言わずに 気持ちよく駒として動かすことに専念すれば？ くーすﾏﾝｾｰとか言ってやれば ドーパミン全開で土木作業してくれるよ w 多少、建設的なネタを。ひが君 「cglib 遅せーから Javassist 使う」 とか言ってないで 直接 ASM 使えよ。まー、バイトコードライブラリ作者は使う側のスキルはアテにしてないと 思うけどな。 　性能： ASM ＞ Javassist（初心者向け） ＞ cglib(初心者向けASMラッパー) 　　　　　　　＞ BCEL ＞ SERP 572 名前：デフォルトの名無しさん mailto:sage [04/10/13 14:56:42] 日記への反応は日記に書けば？あっちでも匿名で書けるんでしょ？ 573 名前：デフォルトの名無しさん mailto:sage [04/10/13 14:58:46] もしくーすがOOAなのかER分析なのかしったこっちゃないというなら俺は興味ないな。 システムの狭い世界での話であっても、OOAと構造化には明らかな壁があるのに OOPLを導入してもその壁をうまく越えられてない人が結構いる。 くーすでクラス図もなしにバウンダリを基準に設計する(と読めたけど違う?)ものなら 壁を越えられない人たち向けには良い指針になるかもしれない。 前に使ったある外注は顧客クラスがあるにもかかわらず、 パスワード変更クラスとメールアドレス変更クラスをつくりやがった。 OOAでの1クラスが、複数のバウンダリに登場するのでバウンダリ基準はいくないと思う。 あと顧客が納得できるモノは画面イメージだけっていうのには諸手を挙げて賛同するけど、 顧客が仕様変更したがるのも画面なわけで、「やっぱり確認画面をいれたい」みたいな 変更要望に強くするためには、その後ろにあるクラス設計がいかに業務にマッチしているかが 重要になってくると思うんだけどお前らはどう思い松か？ 574 名前：デフォルトの名無しさん mailto:sage [04/10/13 15:37:37] 別にさあ、日記に何かいてようがいいじゃん。 少なくとも、ここでどうこういう話じゃない。 プロダクトやプロモーションに関わることなら別として。 また呼び出しくらうよ？ 575 名前：570 mailto:sage [04/10/13 15:37:50] >>573 「くーすが知ったこっちゃない」んじゃなくて、 くーすは「お客さんはそんなこと知ったこっちゃない」って 前提で考えられてるんじゃないかなーって 思ったの。 後半の、「顧客が納得できるモノは画面イメージだけって いうのには諸手を挙げて賛同するけど」と同じでっす。 ちょっと言葉足らずでしたかすんません。 576 名前：デフォルトの名無しさん mailto:sage [04/10/13 16:09:04] >「お客さんはそんなこと知ったこっちゃない」って前提で なるほど。そうかも その他の部分はひが氏の日記を拾い読みした記憶から勝手に脳内保管して 書いているので、見当違いだったらごめん、っていうか指摘してくだちい 577 名前：デフォルトの名無しさん mailto:sage [04/10/13 19:01:57] しかしみんないろんな日記よく読んでるねえ。 みんななんだかんだいってもS2が気になってしょうがないんだね。 578 名前：570 mailto:sage [04/10/13 19:24:45] >>577 まさにそのとおり。からさわぎいくどー。 579 名前：デフォルトの名無しさん [04/10/13 21:03:02] S2ってさ、ひがさん一人で開発してるんだよね？ 開発者として、複数の人が参加して、互いにCheck&確認していった方が、 もっと、いい方向になると思うんだけどなぁ... 一人で開発してると...どうも、一人よがりになりそうで... 580 名前：デフォルトの名無しさん mailto:sage [04/10/13 21:09:02] >>579 あれってオープンソースでやってて、独りで作っているわけじゃないでしょ？ S2Xxxって感じで他の人もやってたような…。 581 名前：デフォルトの名無しさん mailto:sage [04/10/13 21:33:58] うちなーんちゅ記念ｶｷｺ 582 名前：デフォルトの名無しさん mailto:sage [04/10/13 23:19:53] >> 580 コアな部分は全部１人でやってるよ。 583 名前：デフォルトの名無しさん mailto:sage [04/10/13 23:43:03] S2Dao使うにはMySQLは不向きだな。 584 名前：デフォルトの名無しさん mailto:sage [04/10/14 00:05:05] >>579 オープンソースの大半は最初はそんなもんじゃないの？使う人が増えて パイが大きくなったらコントリビューターも増えるでしょ。 つかそうならないと増えないような 585 名前：デフォルトの名無しさん mailto:sage [04/10/14 00:07:17] コアな部分はだいたいどんなプロダクトでもひとりでやってるもんじゃない？ コアとはいえ、全体からすれば一部分なんだし。 586 名前：デフォルトの名無しさん [04/10/14 06:56:40] >>573 > パスワード変更クラスとメールアドレス変更クラスをつくりやがった これの何が悪いのか。 これが適切な場合だって（むしろそのほうが）多いだろ。 587 名前：デフォルトの名無しさん [04/10/14 06:57:10] 顧客クラスにパスワード変更メソッド付けるなんてアフォとしか漏れには思えん 588 名前：デフォルトの名無しさん mailto:sage [04/10/14 07:22:10] ケース倍ケースじゃん。 573のシチュエーションだと変に見えただけじゃないの？ 589 名前：デフォルトの名無しさん mailto:sage [04/10/14 16:25:45] 顧客クラスというからには cust.load(); cust.setPassword(pass); cust.update(); とするだけで更新できるので、わざわざ別クラスつくる意味がまったくわからん。 顧客クラスにパスワードのバリデーションメソッドを追加するだけでいいのに。 わざわざパスワード変更用のクラスをつくってバリデーションと更新メソッドを つくる意味を教えてくれないか？さらにメールアドレス変更クラスは これにそっくりで、バリデーションの内容がちょっと違う(".@"が使える)のと 更新メソッドのsqlがちょびっと違うだけ。クラスの見通しも機能拡張への対応も 顧客クラスにまとめた方がはるかにいいじゃん。 是非俺にも納得できるように説明して欲しい 590 名前：デフォルトの名無しさん mailto:sage [04/10/14 16:36:32] 誰でも自由にクラスを作れて、 どんなクラスでもDBに自由にアクセスできて、 DBが間違いなく更新される以上なにも問題が起きない、 という無法状態を放置しているのがそもそもの間違い。 591 名前：570 mailto:sage [04/10/14 17:11:30] >>589 データと振る舞いをカプセル化するという方向は 実は間違いなんじゃないかという考えもあるんですよ。 エンティティは純粋にデータとしてとらえる。 意味がないわけではないと思いますよ。 ただそれもシステム全体の規模やルールとの兼ね合いも あると思うので、杓子定規に当てはめるのもなあとも思う。 この場合は、印象のみだけど、ちょっと煩雑かなー。 592 名前：デフォルトの名無しさん mailto:sage [04/10/14 17:54:51] >無法状態を放置しているのがそもそもの間違い。 まあそりゃそうなんだが。 >データと振る舞いをカプセル化するという方向は 実は間違いなんじゃないか ちなみに今ウチでは顧客クラスでDataAccess顧客クラスを参照して daoCustomer.setData(this); dao.update(connection); みたいな感じでDAだけ分離する方向です。小規模だとやらないけどね。Connection 渡すのは複数のDAにまたがってトランザクション管理するためね。S2DAOとか 使えば楽になるのかなあと思って興味を持ってるわけだけど。 で、パスワード変更やメールアドレス変更のために別クラスをつくって 似たような処理をいろんなクラスに書きまくった方が良いケースってのは どんな場合よ？画面単位なので名前・住所・電話番号等の変更クラスは 一つにまとまってるんだろうけど。 「これらの画面を一つにまとめたい」とか「メールアドレスに対して パスワードを送付する機能をつけたい」とかの仕様変更に対応するには 顧客クラスが汎用的に(といってもこのシステム内で、だけど)顧客情報を 管理できるクラスであることが重要じゃない？顧客検索みたいに顧客クラスの インスタンスを複数扱う機能には、別に顧客検索クラスをつくるけどさ。 593 名前：デフォルトの名無しさん mailto:sage [04/10/14 20:34:50] >>592 顧客情報と認証情報を別個に分けて管理したい時。 セキュリティのためにね。 >メールアドレスに対してパスワードを送付する機能をつけたい 顧客が希望しても、こういう仕様は止めろよ・・・ 594 名前：デフォルトの名無しさん mailto:sage [04/10/14 21:09:20] >顧客情報と認証情報を別個に分けて管理したい時 そのために内部の実装を分けないといけないようなケースがそんなにあるの？ >>メールアドレスに対してパスワードを送付する機能をつけたい >顧客が希望しても、こういう仕様は止めろよ・・・ 誰でもすぐ会員登録できる情報サイトなんかではこれでいいと思う。 つーか話題とずれてるけど 595 名前：デフォルトの名無しさん mailto:sage [04/10/14 21:21:04] >>592 >ちなみに今ウチでは顧客クラスでDataAccess顧客クラスを参照して >daoCustomer.setData(this); >dao.update(connection); >みたいな感じでDAだけ分離する方向です。小規模だとやらないけどね。Connection >渡すのは複数のDAにまたがってトランザクション管理するためね。S2DAOとか >使えば楽になるのかなあと思って興味を持ってるわけだけど。 S2Dao使うと、dao.update(customer);で済む。 複数のdaoでconnectionを共有するなんてのは、まさにDIの使いどころ。 596 名前：デフォルトの名無しさん mailto:sage [04/10/14 21:38:20] >>591 データと振る舞いを分離するって、Customerクラスと CustomerLogicクラスに完全に分かれるってこと？ 597 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:00:15] >596 で、CustomerLogic を具体的な業務ロジッククラスから呼び出して使えばいいのか。 白黒あいまいな感じで作りやすいかもしれない。 OOしてると、後だしででてきた要件の扱いに悶々と悩むことあるから。 598 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:07:20] 下手するとDRY原則やぶりなコードができそうだな。 さらにS2Dao使うと、SQLの中にロジック散らばりそうだし。 599 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:16:47] データとロジック分けるメリットって？ 600 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:48:16] >>599 メリットは597が言ってる。 でもそのメリットも、システム規模、それとクラスを分けた事による利用性や 他の利便性（DIのアーキテクチャにのりやすいとか他いろいろ）と 応相談ってところじゃないかな。 なんでもかんでもOO的にエレガントだからって押し切ると 業務要件とか実装上の現実問題とかないがしろにしちゃう。 パターンはパターンで有用だけど皆頭使おうぜって所ですか。 S2やくーすが、その頭使おうぜって所を 何処まで軽減できるかってのが、楽しみなところじゃない？ 601 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:48:26] ValueObjectに処理を持たせるという話をしてるの？ 602 名前：デフォルトの名無しさん mailto:sage [04/10/14 23:01:23] >599 OOだと、組み替えたり、整理したり、やっぱこの部分独立させよう、いやいやそこはそのままで、 としてるそばからお客さんに「やっぱりおしごとのやりかたかえますた」って言われてイヤ。 ロジックとデータは分けておいて、diconファイルとかで業務構造を動的に管理するために 計算資源を使ったほうが合理的かも。 603 名前：デフォルトの名無しさん mailto:sage [04/10/14 23:09:27] 業務構造って、えらくあいまいな言葉だな。 データストア層とドメインモデル層を分けて考えるなら、おのずとDAOが出てくるわけだが。 604 名前：デフォルトの名無しさん mailto:sage [04/10/14 23:16:36] S2JSFまだぁ？ 605 名前：デフォルトの名無しさん mailto:sage [04/10/14 23:21:26] >> 603 ドメインモデル層をデータとロジックに分けてしまおうって言ってんじゃないの？ ファウラー氏の言う「ドメインモデル貧血症」に。 606 名前：デフォルトの名無しさん mailto:sage [04/10/14 23:40:01] 601ハ、ValueObjectノ意味ヲハキチガエテマス。 607 名前：デフォルトの名無しさん mailto:sage [04/10/15 00:33:00] >603 設計方法論に詳しいわけじゃないんで、変なこと言ってたらすまん。 処理の方法がころころ変わるような場合の話で。 ビジネスルールをそのままソフトウェアにしちゃいたい。 静的な構造はうまい人が作らないと汚くなるし、 完成するとそれで世界が完結するから変更が大変。 だからソースコードで書く部分をビジネスルール層だけにしてしまう。 それをO/Rツールが自動化してくれるデータアクセス層に被せる。 データは「ビジネスルールが正しく実装された」ことをテストして保障。 うまくいけば楽にならないかなぁ。 608 名前：デフォルトの名無しさん mailto:sage [04/10/15 00:55:06] >>607 ふつーうにS2の実装ってそんな感じじゃないの。 609 名前：デフォルトの名無しさん mailto:sage [04/10/15 03:00:24] ビジネスルールがSQLに分散するんじゃね？ 610 名前：デフォルトの名無しさん mailto:sage [04/10/15 09:44:02] ビジネスルールって言葉が曖昧だよな 611 名前：デフォルトの名無しさん mailto:sage [04/10/15 13:35:54] >>609 どーせ、SQLは山ほど書くんだから問題なし。 612 名前：デフォルトの名無しさん mailto:sage [04/10/15 14:09:21] >>611 山ほど書く中に分散したり、２重になったりがまずいんじゃ。。 SQLバリバリの人だったら、その辺問題ないのかなあ。 613 名前：デフォルトの名無しさん mailto:sage [04/10/16 04:31:40] S2Ayaya を使えばあややのどこにinjectionできますか。 614 名前：デフォルトの名無しさん [04/10/16 04:55:10] もちろん大事なところでしょう。 615 名前：デフォルトの名無しさん mailto:sage [04/10/16 12:56:46] メタについてはどうよ？ 実物がないからなんとも言えんが、 実装者への負担増えない？ 616 名前：デフォルトの名無しさん mailto:sage [04/10/16 14:25:56] >614 RejectedRuntimeExceptionが発生します。 617 名前：デフォルトの名無しさん [04/10/16 21:29:13] >>591 >データと振る舞いをカプセル化するという方向は >実は間違いなんじゃないかという考えもあるんですよ。 >エンティティは純粋にデータとしてとらえる。 >意味がないわけではないと思いますよ。 やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。 おまいら、以下を読んで目を覚ましてくれ。 ---- ドメインモデル貧血症 capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel このアンチパターンが根本的に怖いのは、オブジェクト指向設計の 基本概念（データと処理を一緒にする）の真逆だということです。 ドメインモデル貧血症とは、単なる手続き型設計のことなのです。 まさに、私（そしてEric）のようなオブジェクト信望者が、Smalltalkの 初期からずーーーーーっと戦ってきたもの、そのものなのです。 さらに困ったことに、貧血オブジェクト(Anemic Object) が本物の オブジェクトだと思っているひとがたくさんいます。つまり、 オブジェクト指向設計が何たるかをまったく分かっていない ということなんです。 ---- 618 名前：デフォルトの名無しさん mailto:sage [04/10/16 21:50:51] そういう名前のアンチパターンがあるからといって、それが常に正しくないわけじゃないんだけどね。 619 名前：デフォルトの名無しさん mailto:sage [04/10/16 21:57:31] >やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。 それは、一見ドメインモデルだけどそうではない、ってやつだろう。 591のは、もっと違う考えもあっていいんじゃないか、ってことで。 617は、世の中のソフトはすべて静的モデルで書くべきだ、という考えなのか。 620 名前：デフォルトの名無しさん mailto:sage [04/10/16 22:49:27] 構造化は一時期までかなーり成功を収めた手法だけれど、 OOってまだそこまで大成功は収めていない手法にも関わらず、 ここまで熱烈信者が増えてるのは何故だろう…？ 621 名前：デフォルトの名無しさん mailto:sage [04/10/16 23:09:46] 591だけど、ドメインモデル貧血症の事は知ってます。 だけど、そういったゴリゴリオブジェクト指向マンセーな流れとは 別の流れも最近よく目にします、っていう意味ですよ。 世の中ファウラーの言う事だけが有用って訳ではないでしょう？ 議論の余地があるみたいですね、って話です。 大体貧血症が怖い理由が、オブジェクト指向の基本概念と真逆だから ってだけなのは、ちょっとお寂しいですね。 まあそのページを読むとファウラーさんは結構面白い文章を書く おちゃめさんぽいので、半分ネタといか煽りの気もしますけど。 で、俺の立場としては、所詮DOA育ちなんで 基本的に貧血症大好き、 ただしメンテナビリティなどの事情を鑑みて、 責務割り当てるのもまぁありかなって所です。 そもそもその貧血症だのなんだの、 純血種しか許さない態度が俺は好かん。 622 名前：デフォルトの名無しさん mailto:sage [04/10/17 00:13:43] > OOってまだそこまで大成功は収めていない手法にも関わらず ぽかーん。 まるで、親にメシ食わせてもらいながら「親なんて必要ない」とほざいてる中学生みたいだな。 623 名前：デフォルトの名無しさん [04/10/17 00:15:16] >>620 >OOってまだそこまで大成功は収めていない手法にも関わらず、 ΣΣ(ﾟдﾟlll)ｶﾞｶﾞｰﾝ!! 624 名前：617 [04/10/17 00:30:58] >>621 > 591だけど、ドメインモデル貧血症の事は知ってます。 > だけど、そういったゴリゴリオブジェクト指向マンセーな流れとは > 別の流れも最近よく目にします、っていう意味ですよ。 寡聞にして知らないのですけど、どのへんで見たのか教えていただけませんか? > 大体貧血症が怖い理由が、オブジェクト指向の基本概念と真逆だから > ってだけなのは、ちょっとお寂しいですね。 いや、 ファ> ドメインモデル貧血症問題の本質は、ドメインモデルのベネフィットを何も得ず、 ファ> コストだけをすべて被ってしまうという点です。 とも仰ってます。 もちろん「ドメインモデルなんて使わないで TransactionScript一本」っていうプロジェクトであれば、 ドメインモデル貧血症に該当してもなんの問題もないとは思いますけど。 > そもそもその貧血症だのなんだの、 > 純血種しか許さない態度が俺は好かん。 これはそうですな。反省してます。 625 名前：617 [04/10/17 00:39:55] >>612 > >>611 > 山ほど書く中に分散したり、２重になったりがまずいんじゃ。。 > SQLバリバリの人だったら、その辺問題ないのかなあ。 SQLバリバリだろうがなかろうが問題ありありだと思うよ。DRY原則に反してるわけだから。 # DRY原則は数あるソフトウェアの原則の中でも、最も尊ぶべき原則だと思うなぁ 626 名前：デフォルトの名無しさん mailto:sage [04/10/17 01:50:08] DIともseasarとも関係ない話が続いてるけどなんか面白いな。 混ざってみよう。 これがすばり貧血症にあたるかわからないけど tp://www.relaxer.org/process/sample/library/LibrarySystem1.1.1/LibrarySystem_s4.html エンティティの管理クラスが軒並み外出しになってる。どう？ はぶ氏も日記で「エンティティはDBのテーブル」と位置づけてたと思った。 意図的な極論なのかも知れないが、態度は貧血に近いと思う。 あとファウラーさんも「これはずいぶん昔からあるアンチパターンのひとつですが、 今になって台頭してきているようです。」って書いてるくらいだから やっぱり貧血派は増えてるんではないすかね。 でもそんな違いは誤差だとかってまた言われそうだ。 627 名前：デフォルトの名無しさん mailto:sage [04/10/17 02:07:30] あ、そうか、エンティティがDBのテーブルって事なら ファウラーの言う所の「コスト」はかかってないって事か。 それにDTOと所謂ドメインモデルを合わせた バリュー・オブジェクトって事も言ってますね。 ああ恥ずかしい。 628 名前：デフォルトの名無しさん mailto:sage [04/10/17 02:25:12] まあ、DI、Seasar、くーすの流れだから、関係なくはないかな。 業務アプリ作ってる人全員が、上手いことOOで作ることは無理っていう 前提に、ICONIXやくーすってあると思う。 浅海氏のページ見たけど、要求分析から実装まで通して示してあって いいね。とてもいい。 実装見ると、リファクタリングしたい（やっぱエンティティにもっとロジック 追加したい）って思うけど、上に書いた考えでいくと、酷い訳ではないし、 これっくらいが現実的なOOとのつきあい方かもしれん。 VB + OCXが割と正解だったってことかな。

---

---

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

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