国産オープンソース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/ 449 名前：デフォルトの名無しさん [04/10/08 12:01:27] 何だ羽生氏に話を聞いて欲しい奴が騒いでるだけなのか？ ひが氏もいい迷惑だな >>448 ＞ドキュメントの整備は大歓迎です。ただ他の方に注力して欲しい。 禿同 ひが氏にはどんどんS2を磨いていってもらいたい とりあえず2.1期待ageだ 450 名前：デフォルトの名無しさん mailto:sage [04/10/08 12:38:41] >>449 話をさえぎられて自分の出番を取られてしまった人じゃないの？ 451 名前：デフォルトの名無しさん mailto:sage [04/10/08 15:00:40] やられたらやりかえせｗ 452 名前：デフォルトの名無しさん mailto:sage [04/10/08 15:17:48] >分からん奴らにはメソッドの仕様だけ渡して、 >その部分だけ他に影響を与えずに作らせることができるという ちゃんと詳細設計ができてれば普通のOOPどころか構造化設計でもそうです。 ドキュメントがどうとかは(俺は言ってないけど)せっかく匿名で本音を吐いてくれてるのに それを粘着呼ばわりする被害妄想は止めて欲しい 453 名前：デフォルトの名無しさん mailto:sage [04/10/08 15:37:25] DIだと、影響を与えないための労力が少ない、ってことじゃね？ 454 名前：デフォルトの名無しさん mailto:sage [04/10/08 16:37:56] 枠組みとして用意されているのでいろんなスキルの人がまざっても 平準化しやすい、という事なら納得できるけど。 というか詳細なインターフェース設計をしてからじゃないと実装始められないよ、 ということか。それはいいかも。でも実装し始めてから設計ミスを直すのが めんどくさそうな肝汁 strutsがMVCモデルを強制してもActionにビジネスロジック書く奴がいて、 結局ちゃんとOOAしないとMVCのメリットがでない ↓ ちゃんとOOA出来る人がいたらstrutsの仕組み必要ない (設定ファイルの手間が増えるし。taglibは便利だけど) みたいな事にはならないのかな？全然Seasarの話じゃなくて申し訳ないが 455 名前：デフォルトの名無しさん mailto:sage [04/10/08 17:04:12] DIというか、クラス名やらメソッド名を外部設定ファイルに埋め込むと、リファクタリング機能が効かないから不便かも。 strutsのMVCはアプリケーション全体でいえばVの中のローカルなMVCだからしかたないね。 456 名前：デフォルトの名無しさん mailto:sage [04/10/08 18:15:12] >>453 YES >>454 だからくーすを作ったんじゃないかな 457 名前：デフォルトの名無しさん mailto:sage [04/10/08 19:38:28] >>448 >使う人は、実装を外注しやすくなり、Springと比べてもテストや >設定が格段に楽になります。 まじ参考までに教えて欲しいんですけど、Seaser2がSpringと比べて テストや設定がしやすい部分ってどういうところなんでしょうか？ SpringとSeasar2の比較をいろいろ探したんですが、どれもいまいち ピンと来ないもので。 458 名前：デフォルトの名無しさん mailto:sage [04/10/08 21:32:42] >>452 人をうんこ呼ばわりしてあげつらったヤシが いるんだから被害妄想もある程度仕方ない と漏れは思う。ひが氏の日記が大人しくなって しまったのが個人的には残念だ。 459 名前：デフォルトの名無しさん [04/10/08 21:39:32] 議論のアンチパターン 〜不毛な議論を避けるために〜 ttp://homepage1.nifty.com/fujiwo/develop/oo/dscsnptn.html#chapter4 460 名前：デフォルトの名無しさん mailto:sage [04/10/08 22:59:10] 外注というと書かれるコードの中身は汚くてもいいという印象があってよくない 461 名前：デフォルトの名無しさん [04/10/08 23:06:46] 外注はよくないけど、とりあえずS2について言うと、 欲しい機能を（Javaでやるという前提であるならば）考えられうる限りできるだけシンプルに実装できるもので 割と好印象。 462 名前：デフォルトの名無しさん [04/10/08 23:10:56] 少なくともJ2EEを作った香具師より頭いいのは確かだ 463 名前：デフォルトの名無しさん mailto:sage [04/10/08 23:13:14] 先にinterfaceありきと考えると 仮にコードが汚くてもUnitテストさえ クリアしていれば安心が得られると いう利点があるかなと思うけどどうかな？ 464 名前：デフォルトの名無しさん [04/10/08 23:18:59] >>463 テストをするのは当然で 汚いのはリファクタリングの原則に反するのでよくない 465 名前：デフォルトの名無しさん mailto:sage [04/10/08 23:22:32] もちろんそうなんだけど 外注に出して汚いコード だったとしてもまだ安心度が 保てるように思うんだが 466 名前：デフォルトの名無しさん [04/10/08 23:27:35] 設計は変わるもんだ。外注にやるとプログラマからのフィードバックが得られない。 S2は外注向けと考えるならそれは間違い。もともとソフトウェア開発はそういうものじゃない。 467 名前：デフォルトの名無しさん mailto:sage [04/10/08 23:38:23] ほんとはみんなデスマが好きなのさ。 どっぷりとデスマに浸かることで、 自分は仕事をしているんだ！ という満足感が得られるからなのさ。 さらに、デスマを解消したり 回避する方法を考えるのは もっと好きなのさ。 なんでかというと、 自分はこんなすごいことをやったんだ！ という優越感が得られるからなのさ。 Seasarってのはそうやって生まれたの。 468 名前：デフォルトの名無しさん mailto:sage [04/10/08 23:39:03] 外注に出さないプロジェクトって、小さなプロジェクトか小さな会社くらいでは？ 469 名前：デフォルトの名無しさん mailto:sage [04/10/08 23:45:27] >464 汚いのはリファクタリングの原則に反する、ってのはどういう意味？ リファクタリングの対象になる、ならわかるけど。 ついでにいうとユニットテスト通ってるならリファクタリングも気楽にできるね。 470 名前：デフォルトの名無しさん mailto:sage [04/10/08 23:45:59] >>468 S2の話とはもう違うだろ。 外注に出すところのコスト構造って本当に酷いよ。 471 名前：デフォルトの名無しさん mailto:sage [04/10/08 23:49:42] DI 使うとデバッガ使えないの？ テストうんぬんではなく、 ステップ実行とかできないの？ 472 名前：デフォルトの名無しさん mailto:sage [04/10/09 00:02:32] >>467 おかげでデスマにならずに済むなら漏れはありがたい。 >>471 S2のコードも全部放り込んでおけばいいんじゃない？ 473 名前：デフォルトの名無しさん [04/10/09 01:51:38] >>472 デスマはなくならないよ。 まず>>467でいう満足感と優越感がなくなっちゃうからね。 それに、新たな方法論を導入して解決するのは 「今までのステージにおけるデスマ」であり、 「次のステージにおけるデスマ」が控えているんだよ。 デスマあってのSeasarであり、 デスマある限りSeasatは進化し続け、 そしていつまで立ってもデスマはなくならない。 しかし、これがみんなの幸せにつながる。 474 名前：デフォルトの名無しさん mailto:sage [04/10/09 02:18:01] ＞デスマあってのSeasarであり、 (　ﾟдﾟ) (つд⊂)ｺﾞｼｺﾞｼ 　 (；ﾟдﾟ) (つд⊂)ｺﾞｼｺﾞｼ 　　_, ._ （；ﾟ Дﾟ） …?! '`,､'`,､('∀`) '`,､'`,､ 475 名前：デフォルトの名無しさん [04/10/09 02:58:52] >> 457 設定ファイルやテストコードを書くためのタイプ量がS2の方が少ない。 DIを使うと、これらの煩雑さが問題となってくる。 476 名前：デフォルトの名無しさん mailto:sage [04/10/09 07:44:22] >471 DIは問題ない。初期化より後は普通だから。 でもAOPを使うとデバッガで追えない。 バイトコードいじってるやつ全般に言えることだけどね。 477 名前：デフォルトの名無しさん mailto:sage [04/10/09 08:49:04] >>476 AOPを使っても追えるよ。 意味不明なクラスに行くけどそこもトレース実行すればその後は問題なかった。 478 名前：デフォルトの名無しさん mailto:sage [04/10/09 14:05:50] >>476 デバッガで追えないのは、AspectJ。 S2は普通に追える。 479 名前：デフォルトの名無しさん mailto:sage [04/10/09 15:42:43] >>462 J2EEっていうかEJB？ 後だしじゃんけんだからなぁ。 DynamicProxyのおかげの部分もあるし。 480 名前：デフォルトの名無しさん mailto:sage [04/10/09 16:24:41] >>479 S2はDynamicProxyは使ってないけどね。 cglibでバイトコードいじっているから同じようなものだけど。 481 名前：デフォルトの名無しさん mailto:sage [04/10/09 16:54:24] ・・・そうなんだね。 cglibのページの「Open source projects use cglib」に載ってないのが寂しいけど。 482 名前：デフォルトの名無しさん mailto:sage [04/10/09 23:49:20] バイトコード操作してる地点で実案件に使えるのかなぁ。。 とても使わせてもらえなそうだが。。 483 名前：デフォルトの名無しさん mailto:sage [04/10/10 01:01:18] オイオイ、どういう判断基準なんだ？ といことはcglib使ってるモノはすべてだめなんだね。 HibernateとかSpringとかも。 484 名前：デフォルトの名無しさん mailto:sage [04/10/10 01:37:22] >>483 コンテナ部分は使ってないぞ。Spring。readme.txtに書いてある。 なので、AOPやDAO機能を捨てれば非バイトコード操作なDIコンテナとしては使える。 あと、PicoContainerも非バイトコード操作なDIコンテナだよね。 >>482 なので、あくまでもDIコンテナが使いたいならS2以外の選択もある。 AOPを利用したい時にはS2のほうが簡単だと思うけどね。 485 名前：デフォルトの名無しさん mailto:sage [04/10/10 01:45:20] AOPなければ、意味がかなり減るんだけども。 SpringのAOP定義はめっさめんどり。 486 名前：デフォルトの名無しさん mailto:sage [04/10/10 04:53:02] >>403 偉いなMS。蚊帳の外でもコミットしようとするなんて。 これだけ見るとSUNだめだな。 空のインプリメソッドがゴミのようにある俺のソース…。何とかしてくれ。 487 名前：デフォルトの名無しさん mailto:sage [04/10/10 05:05:49] いろいろ考えたんだけどさ、EJBとかDIコンテナとか やっぱりなんかくだらない気がしてきた。 アプリケーション毎に必要な機能って違うじゃんか。 （負荷分散・クラスタリング・動的再配置・トランザクション・必要になるパフォーマンス、とかいろいろ） シンプルな実装をアプリケーション毎に作ったほうが、ムリヤリ共通して使える実装を探さなくてもいい。 488 名前：デフォルトの名無しさん mailto:sage [04/10/10 05:07:32] シンプルに構造を分割する考え方（〜層、とかいろいろ）の話を延々としているほうがいいと思うよ。 実装はアプリケーション毎に行こう。 489 名前：デフォルトの名無しさん mailto:age [04/10/10 05:15:47] >>455 リファクタをキジムナに期待age 490 名前：デフォルトの名無しさん mailto:sage [04/10/10 05:23:48] >>487 それはアプリ毎に必要な機能じゃなくシステムの構成・設定。 487の言う「いろいろ」こそ共通して使える実装部分じゃろ。 491 名前：489 mailto:sage [04/10/10 05:56:56] >>330 > ところで、S2が正しくinjectionしてくれるかどうかの > テストはどう書けば？（汗） キジムナ使へば下に出るぞ。singletonだけかもしれんが。 それをキャプチャしたのをテスト結果とすると良いかも。 >>399 >>400 キジムナ使え。事前検証バリバリだぞ。 >>作者 コード補完機能ｷﾎﾞｿ 492 名前：デフォルトの名無しさん mailto:sage [04/10/10 08:16:10] >>487 だから、アプリケーションごとに違う非機能要件をAOPを 使って処理するんじゃん。 493 名前：デフォルトの名無しさん mailto:sage [04/10/10 08:30:30] >>486 俺もMSの態度は偉いと思う。 片思いなのがこれまた哀愁がただよってて ヘンに共感してみたり。いやそりゃヨタだけども。 でもコーディング量が増えても インターフェイスという考え方で統一したいって 気持ちもちょっと判るんだよねー。 494 名前：デフォルトの名無しさん mailto:sage [04/10/10 08:36:10] >>490 トランザクションの基盤なんて単純なものならほんの数行のコードで実装できるし、 動的再配置するためのライブラリ（ちょっとしたネームサービス）あればいい クラスタリングや負荷分散となると、それはアプリケーション毎にかなり違うもんだと思う あんまり仰々しいフレームワークを用意されても、結局複雑にしてしまうだけではなかろうか 495 名前：デフォルトの名無しさん mailto:sage [04/10/10 09:05:12] >>487 そんなこといったらJDBCもいらんってことにならんか？ 何を持ってシンプルな実装というかだな。 496 名前：デフォルトの名無しさん mailto:sage [04/10/10 09:41:42] >>494 ぎょうぎょうしいフレームワークって何。 S2はシンプルだと思うけど。 POJOが基本で、コアはDIとAOPの機能だけ。 コア以外の機能もいろいろあるけど、 使えるものは使えばいいし、無理に使わず自前で実装しても良い。 ただ、クラスタリングや負荷分散を自前で実装するやつは、 よっぽどのツワモノだと思う。 497 名前：デフォルトの名無しさん mailto:sage [04/10/10 10:39:55] >>487 EJBはくだらないが、DIはくだらなくないよ。 アプリケーション毎に、というより、アプリケーション内で必要な機能をアプリケーション内で共通して使うためにDI+AOPが有効だと思われ。 498 名前：482 mailto:sage [04/10/10 12:58:13] >483 SpringもHibernateもDynamicProxyで代用できませんでしたっけ？ #フル機能使えなくてもさ DIコンテナってテストが簡単とか、複雑じゃないとか利点ばっか挙げられてるが， 商用EJBコンテナが提供するような分散・スケールアウト手法は確立されているの？ 499 名前：デフォルトの名無しさん mailto:sage [04/10/10 13:02:41] >496 毎回毎回自分で実装できるような奴ならいらんのでしょ。 負荷分散・クラスタリング・動的再配置・トランザクションをシンプルな実装で アプリケーションごとにバグ少なく作成できるような凄い人はうちの周りには いないけどね。 500 名前：デフォルトの名無しさん mailto:sage [04/10/10 13:10:21] >>499 負荷分散・クラスタリングって、パフォーマンスとの兼ね合いでいろいろ調整いるだろうから、 自分で実装っていうのが基本では。 それを補助く小さなライブラリ（タプルスペース扱うやつは便利だ）があれば満足。 501 名前：デフォルトの名無しさん mailto:sage [04/10/10 13:18:19] >>500 スーパーな人発見。 釣りじゃないならすごいね。 そういうのは、アプリケーションサーバか負荷分散装置だとかに 任せるものだと思っていたよ。 502 名前：デフォルトの名無しさん mailto:sage [04/10/10 13:21:07] まぁ、EJBとかに比べると仰々しくは無いのだけど、 Lightweightなプログラミング言語を使っているとどうしても大げさに感じてしまうのよね。 503 名前：デフォルトの名無しさん mailto:sage [04/10/10 13:24:26] >>500 バイトコードいじくるものより、自分で組んだ負荷分散やらクラスタリングのほうがあてにならんなぁ。 トランザクションも、基盤は数行でも、いろいろなところに埋め込まれて、そっちの方があてにならんなぁ。 504 名前：デフォルトの名無しさん mailto:sage [04/10/10 13:27:27] Lightweightなプログラム言語使ってる人って、ライブラリやフレームワークを勉強して数行でまとめて書けるコードを、頭使わず勉強せず数十行あっちこっちに書くほうが手軽だと思いがちだよねぇ。 505 名前：デフォルトの名無しさん mailto:sage [04/10/10 13:31:12] >>501 貧乏人は自分で作るんですよ。多分。 506 名前：デフォルトの名無しさん mailto:sage [04/10/10 13:32:18] スケールアウト、負荷分散いらないんじゃそもそもEJB使ってねえぞ。 これらの機能提供しないのに，EJBの代替物と歌われてもねぇ、、、 507 名前：デフォルトの名無しさん [04/10/10 13:33:55] >>505 作っているものによると思うけどね。 一体どういうものを想定している？ HTML文章返すだけのウェブサーバとネットワークゲームのサーバではそりゃ負荷分散の手法は違ってくる 508 名前：デフォルトの名無しさん mailto:sage [04/10/10 13:40:01] 基本的に業務システム以外は対象外だからねぇ。 509 名前：デフォルトの名無しさん mailto:sage [04/10/10 13:40:48] というか、ネットワークゲームのサーバーでEJBがどうのこうのいうほうが間違ってる。 510 名前：デフォルトの名無しさん mailto:sage [04/10/10 14:26:38] >>509 そこはそれ、アプリ層のインプリだけ構造を統一するためにEJBの スタイルを借りて、サーバー部分は最適化したものを自作、デスよ。 …ほんまかいな。 511 名前：デフォルトの名無しさん mailto:sage [04/10/10 14:38:02] ネ申？ 512 名前：デフォルトの名無しさん mailto:sage [04/10/10 14:40:51] 自ｲ乍ﾈ申 513 名前：デフォルトの名無しさん [04/10/10 14:48:56] どの層で分散がいるかなんて、これはアプリケーション毎に違うでしょ？ どでかいコールセンターで検索したい人が多いなら単にデータベースを大量に水平に並べればよい。 核爆発シミュレーション計算の分散も基本的にはコンピュータ並べるが、自作率は後者のほうが多くなるだろうな。 514 名前：デフォルトの名無しさん mailto:sage [04/10/10 15:03:27] >506 EJBの代替物とは謳ってないんじゃない？ J2EEの機能を使いやすくする、でしょ。 J2EE=EJBだと思ってるなら間違い。 ついでに言うとまだ発展途上なのに「全部無いなら使わん」とかいうならご自由に。 使いたいとこ、使えるとこだけ使えばいいんだ。 あとは自作なり他製品と組み合わせるなり。 515 名前：デフォルトの名無しさん mailto:sage [04/10/10 15:06:12] 語尾に「なり」をつけるやつは嫌いだ。 516 名前：デフォルトの名無しさん mailto:sage [04/10/10 15:07:29] >>513 とりあえず対象となってない分野をもってきて、使えないとかわめくのって、悲しいね。 517 名前：デフォルトの名無しさん mailto:sage [04/10/10 15:13:06] >>506 いつからEJBの主目的が負荷分散になったんだ？ 518 名前：デフォルトの名無しさん mailto:sage [04/10/10 15:14:39] EJBの代替物にもなってないしねぇ。 519 名前：デフォルトの名無しさん mailto:sage [04/10/10 15:16:13] いや、当初から主要な目的の一つではあったが…。 負荷分散しないのにEJB使っても今ひとつ甘みが無い。 520 名前：デフォルトの名無しさん [04/10/10 15:16:25] >>516 クラスタリング・負荷分散に共通して使える対象なんてありえないってことを示す例 521 名前：デフォルトの名無しさん mailto:sage [04/10/10 15:18:24] 業務システムに絞れば、共通して使えるしくみはあるんだけども。 で、とりあえずS2が話題にしてるのは業務システムなんだけども。 522 名前：デフォルトの名無しさん mailto:sage [04/10/10 15:20:57] S2に限らずDIな連中が言ってるのは EJBを使うのは大袈裟なシステムが 世の中には多いんだから別の手を 使おうぜってことでしょ。EJBが必要な 人はそっちを選べばいい。 523 名前：デフォルトの名無しさん mailto:sage [04/10/10 15:21:36] まずは軽快なJavaを読めということでFAだな 524 名前：デフォルトの名無しさん mailto:sage [04/10/10 21:28:23] それは負荷分散をしないって手？ 525 名前：デフォルトの名無しさん mailto:sage [04/10/10 21:35:31] 負荷分散なんて、DBやアプリケーションサーバーにまかせればいいから、プログラムでは考えなくていい。 いくつかの注意点はあるけども。 526 名前：デフォルトの名無しさん mailto:sage [04/10/10 22:39:39] APサーバに任せるメジャーな手段が、EJ(r 527 名前：デフォルトの名無しさん mailto:sage [04/10/10 22:58:32] つか、なんかどーでもよいことに話がいってない？ 負荷分散やらクラスタリングなんかDIコンテナで解決する問題じゃないし。 （てか、んなことまでサポートしだしたらLightweightなコンテナじゃなくなるじゃん） もう少しS2自体の話があるとうれしいのだけど。 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が割と正解だったってことかな。 629 名前：デフォルトの名無しさん mailto:sage [04/10/17 03:37:46] 626のサイト、とても勉強になりました。 ICONIXを基に、より包括的なプロセスになってる。 くーすは、ICONIXから無くしてもいいんじゃないかという部分を省いた、 軽いプロセスを目指してるんですね。ただ、常人には難しそう。 Relaxerプロセスを一通り実践して、カスタマイズしていくのが一番良さそうです。 Relaxer自体はどうだろう。自動生成のデータベースアクセスは重たそうだったけど。 完全にスレ違いになってしまいました。 630 名前：デフォルトの名無しさん mailto:sage [04/10/17 09:05:34] >>629 どこが、常人に難しそうなの。 631 名前：デフォルトの名無しさん mailto:sage [04/10/17 10:40:20] 最近は、ドメインモデリングより、振る舞いのモデリングに シフトしつつあると思う。 ドメインモデルはER分析した結果を使う。 (Entityとテーブルはほとんど同じ) 画面は、欲しい形でDTOとして受け取る。 DTOなので振る舞いを持たない。 DTOとEntityの相互変換をおこなうのは、 コストがかかるので、業務ロジック層や データアクセス層で直接DTOを処理する。 これがくーすの考え方なんだと思う。 それを支えているのがS2Daoで、ほとんどコストをかけずに DTOを処理できるようになっている。 632 名前：デフォルトの名無しさん mailto:sage [04/10/17 11:06:45] > DTOとEntityの相互変換をおこなうのは、 > コストがかかるので、業務ロジック層や > データアクセス層で直接DTOを処理する。 これは大きな間違いだと考える。 そのコストはオプショナルなコストではなく、必須のコスト。 必須のコストを減らす目的で他のマッピングツールを作ったほうがいい。 (DTO <-> Entity(≒ドメインモデル) を相互変換するような) 633 名前：デフォルトの名無しさん mailto:sage [04/10/17 11:19:55] >>632 必須であるわけは。 業務ロジックは、画面のためにあるんだから、 画面に適したDTOを扱うのは自然だと思うけど。 634 名前：デフォルトの名無しさん mailto:sage [04/10/17 11:33:13] システムを層に分ける。 データストレージ―(1)―ビジネスロジック―(2)―プレゼンテーション ここを流れるデータを分類する。 (1)は DTO<->ドメインモデル (2)は ドメインモデル->View用モデル(左から右のみ) ドメインモデルをDTOと同じ構造にすることができるのは、 データストレージ層を新規に設ける場合のみ。 DBスキーマを新規にゼロから構築するケースがどのくらいあるだろうか。 ほとんどないのが実情だ。 ドメインモデルとDTOを一緒にしたいという方向から考えると、上記モデルとは矛盾する。 俺は上記モデルから考えるからこそ、ドメインモデルとDTOは一致しないという立場にたつ。 実際、(1)と(2)で別クラス(実際には別インタフェース)を作ってから実装させたことがある。 DB操作、ビジネスロジック、プレゼンテーションを綺麗に作業分担させられたよ。 635 名前：デフォルトの名無しさん [04/10/17 11:44:16] >>628 > 業務アプリ作ってる人全員が、上手いことOOで作ることは無理っていう > 前提に、ICONIXやくーすってあると思う。 くーすはそうかもしらんが、ICONIXはそんなこと言ってないと思うんだが? Use Case Driven Object Modeling with UML(ユースケース入門)で読んだ知識しかないんだけどさ。 636 名前：デフォルトの名無しさん mailto:sage [04/10/17 12:04:21] >>634 ドメインモデルとDTOは、もともと一致するものじゃないと思うけど、 コストをかけても良いなら、 テーブル<->ドメインモデル<->View用のモデル(ViewHelper) を相互変換しても良い。 きれいな設計というのはものすごくあいまいな言葉で、 自己満足にすぎない可能性もある。 内部スキーマ、概念スキーマ、外部スキーマの考え方は、 昔からあるけど、各スキーマの構造のミスマッチを解消するための コストがかかるから、実際にはあまり使われていない。 637 名前：デフォルトの名無しさん mailto:sage [04/10/17 15:42:09] まず前提。Domain ObjectとDTOの相互変換はめんどくさい。 FowlerのPofEAAのService Layerの説明のところに確か 「DTO変換のコストを過小評価するな。オブジェクトのツリーが 深くなるとすげー辛い」みたいなことが書いてあったはずだ (いま本が手許にないので正確な表現はわからん)。 俺も「Presentation層のコントローラ(この時はStrutsのAction)は Service Layerを介してDTOを受け取り、Domain Objectには絶対 直接触らない」ってポリシーで設計したけど結局実装とテストが やたらしんどくなって方針転換したことがある。 んで、DTO変換をしないとなると、Domain Object側に巻き込むか、 DTO側に巻き込むかという二者択一となる。最近のひが氏は後者に 転んでいる模様。 # ttp://d.hatena.ne.jp/higayasuo/20041010#1097399686 とか ちなみに俺の上記のケースは細粒度のDomain Objectのトランザクション間 かつコントローラ間のロングキャッシュが非常に重要なドメインだったので 前者を選択したよ。 # ひが氏はロングキャッシュは知らんとか言ってるけど。 # ttp://d.hatena.ne.jp/higayasuo/20040808#1091933710 638 名前：デフォルトの名無しさん mailto:sage [04/10/17 16:43:55] >>633 業務ロジックは画面のためにある、というのは違うでしょ。 画面の目的は２つ。 　・業務ロジックを起動するための情報を収集する(=入力画面) 　・業務モデルに関する情報を提示する(=参照画面) 639 名前：デフォルトの名無しさん mailto:sage [04/10/17 17:35:07] >>637 よくわかる説明だけど、わかるやつにしかわからんってなってるかも。 640 名前：デフォルトの名無しさん mailto:sage [04/10/17 18:18:33] >>638 それ、なにが嬉しいの？業務ロジックのために人は画面に情報を入力するの？ 業務ロジックが画面のためにあるというのは違うと思うけど。 あくまで、印刷とか、ファイル転送とか画面をIFとしない業務ロジックもあると思うから。 >>633 こっちの方が正しいんじゃない？ 641 名前：デフォルトの名無しさん mailto:sage [04/10/17 18:49:29] >>640 >>638の1行目を穴が開くまで読むべし。 642 名前：デフォルトの名無しさん mailto:sage [04/10/17 18:56:47] >>641 穴があいたら、次はどうすればいいですか？ 643 名前：デフォルトの名無しさん mailto:sage [04/10/17 19:01:05] >>642 入るしかないでしょ。 644 名前：デフォルトの名無しさん mailto:sage [04/10/17 19:52:07] 入れるしかないよ。 645 名前：デフォルトの名無しさん mailto:sage [04/10/17 20:19:25] 入れるから穴があくんだろ。逆転してるぞ。 646 名前：デフォルトの名無しさん mailto:sage [04/10/17 23:33:54] はぶ氏の長文は、リファクタリング前のコードと同じ臭いがする。 647 名前：デフォルトの名無しさん mailto:sage [04/10/17 23:59:45] 俺らは研究者じゃなく、売り物を売ってんだから、新しかろうと古かろうと コストが低く品質のいいソフトが作れる技術を選べってことだろう。 構造化もOOも上記を実現するためのものの筈だ。 清く正しいOOに固執するあまり、逆に生産性を下げて しまってるのはマズいな。 ER分析と構造化手法に上手くOOのおいしいとこだけ取り込んでっていう くーす的なやりかたが「今の時点」の正解だと思う。カスタマイズは自分らの 貯蓄に合わせてすればいい。 で、正しいOOの負の部分が解消されるようになれば（OODBの性能があがって安くなるとか） すれば、それを使えばいい。 DIやAOP、ORMに関しても、効果と新しいコストとのバランスが重要で、 その点がS2が優れてるんだな。 ということで、Seasar2マンセー！S2Daoマンセー！S2JSFも（多分）マンセー！ 648 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:09:33] まったく同意。本当、からさわぎ楽しみ。 でも仕事の頭からちょっと離れると、 やっぱファウラーの文章とか読むとワクワクするんだよね。 そんな自分も居るのが判ってるんで、ちょっと悔しいというか さみしいというか。 だから617の気持ちも判るんだよなー。 649 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:10:53] リファクタリングして説教して来いｗ みんなが>>646に期待してるぞ 650 名前：647 mailto:sage [04/10/18 00:30:39] >>648 >やっぱファウラーの文章とか読むとワクワクするんだよね。 その辺は先行投資だね。 関数型言語や形式仕様なんかも、そのままの形で仕事に使えないかもしれないが、 懐を広げておくのは開発者として重要だと思う。 ただ、いつの間にかその学習コストを客に押し付ける格好で、実案件に適用しようと 考えてしまう。 「この技術を使っています。だからこれだけ値段が上がります。」ってのは通用しない。 「この機能がこれだけ安く実現されます。」「この作業がこれだけ軽減されます。」 これを末端開発者も忘れないように気をつけたいね。 651 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:45:33] >650 ありがとう、なんか気が楽になりましたよ。 気が楽ってのは、けして安くない本を 会社の金でパカパカ買って乱読しちゃった 罪の意識が楽になった、って事だけど（w 652 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:47:45] まあ、スレ違いかもしれんが、こういった話無しにS2の良し悪しは語れんからな。 653 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:59:42] 書籍代なんて誤差の範囲だよ。 プププ 654 名前：デフォルトの名無しさん [04/10/18 02:34:48] 結局、はぶさんは TransactionScriptでいーじゃんか、ってことか。 くーすもTransactionScriptをベースとしてんの? 655 名前：デフォルトの名無しさん mailto:sage [04/10/18 02:46:23] >. 654 TransactionScriptだろうとMDAだろうと、今使えて、生産性向上とコストダウンを 実現できるやりかたでやるということだろ。客の利益になる物を作って、お金を頂いて 生活してることを忘れるな。 って、所詮2chか。S2にもフォーラムが欲しいな。 656 名前：デフォルトの名無しさん mailto:sage [04/10/18 04:21:56] >>655 みんな各自のblogで満足してるから、実現性は低いね。 657 名前：デフォルトの名無しさん mailto:sage [04/10/18 07:58:24] >>637 ドメインオブジェクトにViewHelper的な要素を 持たせるということなら反対。 むきだしのドメインオブジェクトなら、画面では激しく使いづらい。 658 名前：デフォルトの名無しさん mailto:sage [04/10/18 09:28:58] >>655MLじゃ駄目なの？ 659 名前：デフォルトの名無しさん mailto:sage [04/10/18 15:53:43] >655 コイツはなに当たり前のこと偉そうに言ってるんだ？ 生産性とコストダウンに加えて拡張性とメンテナンス性も向上させるのに OOの中でもどういう手法をとったら効率がいいのか話あってるんだろ？ はぶか？ 660 名前：デフォルトの名無しさん mailto:sage [04/10/18 16:07:11] 「客だよ、客！」 「利益なんだよ、利益！」 「コストダウンっつたらコストダウン！」 文脈を無視してこれしか言わないのはハブだろ。 じゃなければハブのクローンか。 661 名前：659 mailto:sage [04/10/18 16:08:44] どちらにしろ匿名で言い合っている中で人物名だす必要はなかったな。 あやまっときます。すんません 662 名前：デフォルトの名無しさん mailto:sage [04/10/18 18:00:26] じゃあこれからは人物名「はぶ」ではなく機器名「Hub」ってことで。 663 名前：デフォルトの名無しさん mailto:sage [04/10/18 18:56:32] 納期とか予算とかがまずあって、手法はそのあと、とかそういう考え方って、サービス残業しろ、間に合わなければやっつけで、っていう考えにたどりつきがちだけどね。 ソフトウェアの開発は気合でうまくいくものではないと思うんだけど。 「客優先」「利益」「コストダウン」って、サービス残業させるための「魔法の合言葉」だね。 「やればできる。」 長期的に品質(含納期・予算)を確保するためには手法が必要だと思うんだよね。 手法にもてあそばれるのは良くないけど。 664 名前：デフォルトの名無しさん mailto:sage [04/10/18 19:08:31] > 客の利益になる物を作って、お金を頂いて生活してることを忘れるな。 という考え方も、古いね。 サービスの対価としてお金もらってるんだから。主従関係ではないよ。 金額にみあったサービスを提供できればそれでいい。 それができないのは問題だけどな。 665 名前：デフォルトの名無しさん mailto:sage [04/10/18 19:14:28] >>663 それははぶについてでなくて一般論だよね？ はぶは手法としてはくーすカスタムなわけで サービス残業うんぬんの負荷の軽減を 言ってるわけで。 ほっときゃ本人があっちに書くか。楽しみにしていよう。 666 名前：デフォルトの名無しさん mailto:sage [04/10/18 19:18:17] 今の流れって前向きなの？ム板ですべき話なのかな？ 技術のギの字も出さずにただ現場の話がしたいだけなら マ板いけば？ って、所詮2chかｗ 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()欲しい。 所詮２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屋がまるでイスラエルとパレスチナの様で、 日米の文化の違いはかなりのもんの様です。 でもアメリカさんだから、ジョークというか 比喩かも知れないですけどね。 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 803 名前：デフォルトの名無しさん mailto:sage [04/10/23 22:08:24] ttp://d.hatena.ne.jp/akon/20041023#p2 こんな未来は嫌だ。 804 名前：デフォルトの名無しさん [04/10/23 23:03:29] どう作業分担するかで悩んでるらしいけど、 参考になるのはEclipseだと思うよ。Javaで作られた唯一役に立つソフトウェアだ。 これの開発方針を見れ。 805 名前：デフォルトの名無しさん [04/10/23 23:05:49] > Stateless BusinessLogicパターンのメリット > ttp://d.hatena.ne.jp/higayasuo/20040805#1091664617 上記サイトの内容で疑問点がありまして。 ひがさんは 「Statelessにするとメソッド間の依存関係を0にできる。 あるメソッドの呼び出しが、別のメソッドに影響を与えることはない。」 と仰っています。 ここでいう「メソッド間に依存関係がある」というのは、 あるメソッド(以下 Ma)と別のメソッド(以下 Mb)が共に、あるステート(以下 S)に 依存しているということに他ならない。 このステートSをクラスの外に出したところで、Maと Mbが Sに依存していることには変わりない、 つまり Maと Mbは間の依存関係を0にできていないと思うんだけど。 806 名前：デフォルトの名無しさん [04/10/23 23:27:38] >>805 だいたいゼロってことで、それでいいじゃん。 そんなん深く考えてもしょうがない。 807 名前：785 mailto:sage [04/10/23 23:35:51] >>805 ステートSがオブジェクト変数だとMaかMbからのみ変更される って事だからだと思うよ。 ステートSをクラスの外に出すと、MaやMbはステートSに依存 はするけれど、MaとMbの依存関係は無くなるんだね。 よって、MaのテストはステートSの取りうるパターンのテストを 考えれば良いと。Mbがさらに何かに依存しているとテストパターン が依存度倍になると。 でもステートSを隠蔽することがオブジェクト指向じゃんって思うけど ここが、Blogに書いてあるように業務ロジックの変更頻度との兼ね合い なんだろうね。 808 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:44:01] statelessって「実装に依存しない」って意味なんじゃないですか？ 依存関係はインターフェイスで全て捉えるって意味だと。 違ったのかな。 stateless 【形-1】 国［国籍｛こくせき｝・市民権｛しみんけん｝・国家統治権｛こっか とうち けん｝］のない 【形-2】 《コ》処理状態｛しょり じょうたい｝を把握｛はあく｝しない〜◆【対】stateful って辞書にあるそのまんまの意味だとばっかり思ってました。 809 名前：デフォルトの名無しさん [04/10/23 23:48:50] d.hatena.ne.jp/higayasuo/20040805#1091664617 810 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:51:34] >>808 HTTPはステートレスってことは、実装に依存しないって意味なのか？ > 処理状態｛しょり じょうたい｝を把握｛はあく｝しない そのままじゃないか。 どこにも「実装に依存しない」とは書いてないぞ 811 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:52:33] >>808 かなり根本から間違ってるな。State が lessなんだぞ。 812 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:57:32] >>808 SLSB/SFSBの違いを思い出せ。 813 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:58:14] オブジェクトが状態をもたない。 814 名前：デフォルトの名無しさん [04/10/23 23:59:14] class Foo { int s; int method(int x); } があったとして、method(x)っていう呼び出しの結果がxの値だけじゃなく sの値にも依存すればstatefulで、 xの値のみに依存すればstatelessなんじゃね？ だから ＞Statelessといっても、すべてスタティックメソッドにすれば良いという っていうことになるんだと思ったけど 815 名前：デフォルトの名無しさん [04/10/24 00:01:29] >>814 statelessでもポリモフィズムは使いたい。 816 名前：デフォルトの名無しさん [04/10/24 00:03:16] >>814 >すべてスタティックメソッドにすれば良いという ポリモーフィズムが使えるところが違うっていうところだな。 システムをプラグイン的に拡張していけるっていうのがありがたいんだろう。 これやるとプログラマのシステムの意図の理解に役に立つし。 817 名前：805 [04/10/24 00:07:34] >>807 > >>805 > ステートSがオブジェクト変数だとMaかMbからのみ変更される > って事だからだと思うよ。 > ステートSをクラスの外に出すと、MaやMbはステートSに依存 > はするけれど、MaとMbの依存関係は無くなるんだね。 そうかな? 「MaとMbが依存関係とみなされている理由は、ステートSに依存するから」 なら 「クラスの外に出したステートSに依存するメソッドは全て依存関係にある」 と言えると思うんだよね。 818 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:09:28] >>804 ポインタ希望 819 名前：785 mailto:sage [04/10/24 00:33:53] >>817 じゃあMcってメソッドを追加してこれもステートSに依存するとしよう。 Mcをコールした後にMbをコールした場合、Maは一度も呼び出されて いないのに、MbはMaに依存しているっているって言える？ あくまでステートSに依存しているだけだよね。 あとは、ステートSの場所についてだけどこれは　>>813 って事だね。 820 名前：805 [04/10/24 00:37:11] メソッドの処理がステートに依存するクラスの例として 以下のクラスがあったとする。 class File void open(); void close(); int read(); } これが以下のようにStatelessになったところで open、close、readの依存関係がなくなったとは言えないと思うんだよね。 例が悪いのかな? class File { void open(FileState state); void close(FileState state); int read(FileState state); } 821 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:47:37] だからステートって具体的なメンバ変数だの それをクラスにして外に出すって事じゃないでしょ。 810の言う通りHTTPがステートレスというのと同じで 「状態を持たない」って事だと思って読んでたけど。 状態を持たないだと判りにくいか、 状態の変化を管理しない。 S2コンテナの考え方は、オブジェクト間の関連は インターフェイス同士の関連だけ定義して 実装はdiconまかせでしょ、どんな実装をされるかが オブジェクトにとって「状態の変化」でしょ、 だから、オブジェクトは「状態を持たない」 って思って読んでたよ。 結果的に「実装に依存しない」ってのは、 割と外れちゃいない気がする。 822 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:47:53] ひがさんのblogで例に挙がっている、手数料計算なんかだと ドメインモデルではStrategy/Stateパターンになるよね。 そうすると、 aModel.手数料計算()メソッドは、aModel.set手数料計算方法()に依存する。 この計算方法は各業務に付随するものなので、業務ロジッククラスのメソッドで あるべき。aLogic.手数料計算(anEntity)の方が、自然だとは思う。 823 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:50:36] ああでもよくわかんねぇ 824 名前：デフォルトの名無しさん [04/10/24 00:50:40] class File { static int read(String filename, int position); } これは？ 825 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:52:15] なんか俺も混乱してきたのでひがさんきぼんぬ 826 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:54:09] ここへ来て基本的な知識不足が露呈したなあ。 ああ自分が恥ずかしい。 あ、821=823です、 まぎらわしくなっちゃってすみません>822 827 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:54:10] >>820 オブジェクトをステートレスにしろって事じゃないの？ 下の例だとＦｉｌｅＳｔａｔｅオブジェクトさえ作れば、 readメソッドのテストにopenメソッドは必要ない（場合がおおくなる）よね。 上の例だと、クラスにFileStateオブジェクトを持ってるって前提で、 readメソッドのテストにはopenメソッドが必要ってことになるよね。 828 名前：785 mailto:sage [04/10/24 00:58:40] >>820 何に対して、誰から見るとStatelessなのか、Statefullなのか って事だよー。 上のFileクラスは、使う側から見るとopen、close、readのメソッドが Statefullなんだけど、下のFileクラスは、引数のstateに対して statefullであって、open、close、readの関係はStatelessだよ。 ようは、stateだけ考えてれば、良いって事。 ん？漏れはコアなseasar利用者じゃないんだが。。。 モンキーターン見てくる 829 名前：805 [04/10/24 01:00:19] >>819 > >>817 > じゃあMcってメソッドを追加してこれもステートSに依存するとしよう。 > Mcをコールした後にMbをコールした場合、Maは一度も呼び出されて > いないのに、MbはMaに依存しているっているって言える？ > あくまでステートSに依存しているだけだよね。 今思ったんだけど、Maと Mbは依存関係にある、という認識が間違いなんじゃないかな。 Maと MbはステートSとのみ依存関係にあって、互いの依存関係なんてものは最初からない、と。 へんなこと言ってるかな? > あとは、ステートSの場所についてだけどこれは　>>813 > って事だね。 そうです。 830 名前：805 mailto:sage [04/10/24 01:05:18] >>828 > >>820 > 何に対して、誰から見るとStatelessなのか、Statefullなのか > って事だよー。 > 上のFileクラスは、使う側から見るとopen、close、readのメソッドが > Statefullなんだけど、下のFileクラスは、引数のstateに対して > statefullであって、open、close、readの関係はStatelessだよ。 > > ようは、stateだけ考えてれば、良いって事。 > > ん？漏れはコアなseasar利用者じゃないんだが。。。 > モンキーターン見てくる 混乱させてごめんなさい。 レスは、今日はもう寝ちゃうので、また明日以降に。 831 名前：デフォルトの名無しさん mailto:sage [04/10/24 02:51:26] ハイレベルな話題で盛り上がっているところ悪いんだけど、教えてほしい。 何回か話題に出ている「ドメインモデル」ってなに？ ぐぐってもNT Domainばっかひっかかるよ。。 832 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:14:28] ドメインモデル->実世界の構造のウツシミ 833 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:17:11] 結局、こういう「だから何？」的な答え方になるんだよね。 これでわからなければ、一から説明しないといけない。 834 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:20:59] モデリングの本とかで問題領域とかいわれてる部分。 簡潔に一言でいうの、頭よくないと出来ないと思う。 だから本とか読んだ方が早い。 835 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:23:09] あ、そうか、だからぐぐるんなら オブジェクト 設計 モデリング 問題領域 とか周辺の言葉を組み合わせでやってみれば いいかも。 836 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:44:42] なんでも突き詰めると 「絵画の本質は絵を描くことだ」 みたいな、だから何？的な結論になるんだけど、その過程をたどってない人にはその意味や価値がわからないんだよね。 837 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:01:43] 児玉センセの「UMLモデリングの本質」あたりを読むと いいかもしんない。わりと薄いし。けど濃いめ。 釈然としない所もあるけどさー。 838 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:08:57] > 釈然としない所もあるけどさー。 どういうところ？ 839 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:19:41] 2chの議論系スレッドの鉄則。 よっぱらったら書き込まない。 でも、なんか、ヱビスについてるフィギュアでシーサーがついてきて、なんとなく嬉しくなったので書き込み。 こういうビジネスモデルの場合はこういうモデルにするべき、そうじゃなくてこうするべき、って議論はとっても役に立つんだけど、そもそも、「こういうビジネスモデルの場合」があてにならないのはいかがなものか。 特に、間にわけのわからない人が挟まってる場合は顕著。 「これはこうで、そこまでは必要ないから」っていわれて、実際の利用先に行くと、「いや、これはこうじゃなくてそこまで必要、とっても重要」とか言われること多数。 どうするべきよ？ どうよ？ 840 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:30:49] >>838 大変面白く読めたし、勉強にもなりましたが 実装レベルに変換する、としておいて OODBじゃなきゃだめよとなってるので どうも現実感が湧かなかったのです。 その釈然としない所からO/Rマッピングを 色々調べだしまして、S2Daoに行き着いた時は 感激でしたわ。 841 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:32:09] >>839 マジカの出番かな？ 842 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:59:47] マジカ？ 843 名前：デフォルトの名無しさん mailto:sage [04/10/24 05:01:25] >>840 OODBは、RDBの成熟度の高さに打ちのめされた感じだね。 844 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:31:16] 結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。 845 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:48:45] Stateless, Statefulの違いって、DIコンテナとの相性があるのではないだろうか。 ttp://d.hatena.ne.jp/higayasuo/20041024#1098580377 > Statefulでやる場合、状態Sを持ったJavaBeansをnewして作成し使うことになるでしょう。 >そうすると、クライアントは、インターフェースではなく、実装クラスに依存することに >なります。それを避けるために、すべての状態ごとにFactoryクラスを用意するのは、面倒 >でコストがかかります。 >Statelessでやる場合は、実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。 S2DaoのBeanアノテーションをSeasar2.1のmetaタグにしてしまえば、 Factoryクラスはいらなくなるんじゃないでしょうか。 さらに、S2DaoがBeanを作成する際にinjectDependency()すれば、業務ロジックをもたせる ことが簡単になると思います。 >こう考えていくと、プレゼンテーション層から最初に呼び出されるクラスは、 >Statelessにすべきだと思います。 この「プレゼンテーション層から最初に呼び出されるクラス」というのが ファウラー氏の言う「薄いサービス層」ですね。 846 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:58:45] >>845 その文脈でS2Daoを引き合いに出す理由が不明 ファウラー氏とひが氏のいうことを無理にあわせるのはよくないと思う。 847 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:00:29] >>843 OODBはOOがどうのという前にDBとしてこれからなんだろうね。 RDBだって数10年かかって今の地位を築いたんだからこれからだろう。 848 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:04:19] >>846 俺は>>845じゃないけど 「UMLモデリングの本質」を読んだら OODBじゃないとだめよっていってるので （RDBじゃ駄目なのかと）釈然としなくて O/Rマッピングを調べたらS2Daoに出会えて 感激した っていってるんだろ？別にファウラー氏もひが氏も 出てきてないぞ。 849 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:11:58] ttp://nekop.programmers.jp/diary/?date=20041024 これ読んだらEAは俺には縁のない世界だと思った。 うちの会社はオフショアにまっしぐらだorz 850 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:12:46] >>846 薄いサービス層のことなら、何も無理にではないですよ。 まさに合致していると思います。 S2Daoをだしたのは、「実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。」に対応していて、StatefulなBeanを生成する際でも、DIContainerにある程度面倒みて もらうことができると思ったんで。 851 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:18:07] >>849 うちの会社の競争相手は中国人 orz.. 852 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:25:51] >>803 安心するヨロシ。 構造化や正規化すらできない、まともな仕様書すら書けない、要件定義だってできない。 そんな元請けがNやら何やらって名前だけで仕事とって丸投げする連中が、 くーすでオフショアなんて無理だって。 できる連中は今でもできるだろうし、そんな案件は元からうちにはこないアルよ。 853 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:26:46] 先に誰かが書いていたアメリカの事情とか、 Fowler氏の前提としているEAとかあわせると 日本国内で一体どれだけの会社がEAを 必要としているのかという疑問が出てくるな。 漏れの会社は大手の下請ばかりやってるけど、 こんな案件はこないよ。そうじゃない案件は 大連と競合してるよorz 854 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:47:18] >794 >>漏れ的には、迷ったらメンバーで相談する。 これすごく大事。そして相談できるようなプロジェクトはいいプロジェクトだと思う。 ところが世の中には「1年生」とか「ひよこ」とか人材派遣会社から送り込まれてくるJava初心者どころか プログラム初心者とか三国人とかがたくさんいるところも多い。 そういうところではカッチリひとつの方針を決めないとやってらんないんだよね。 855 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:53:57] 段々と下請の悲哀を語るスレと化してきたな 856 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:56:26] 結局、ソフトウェア開発の本質的で構造的な問題だからな。 857 名前：デフォルトの名無しさん [04/10/24 12:09:28] 要するに悲哀感じるのは経営者がソフトウェア制作のことを分かってないから。 しっかり理解して投資していいチームを作るってことが重要なの。 858 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:20:20] >>857が投資していいチームを作って漏れをやとってくれYO 859 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:29:31] 問題は>>858が良いメンバーか、ということだが… 860 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:51:24] >>857 その投資の原資はどこからもってくれば良いのでしょうか？ 861 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:57:45] 資本金。 862 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:09:16] >>861 資本金を投資する以上、一定期間後にはキャッシュリターンの実現が必要。 本当にキャッシュがリターンされるの？ 各担当者の技術レベル向上が収穫とかいう寝言はやめてくれよ（藁 863 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:11:12] データと処理は分離、という点でいくと、ORマッピングで継承使ったときに、ポリモーフィズムで処理を切り替えることについてはどう考えたらいいのかな。 864 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:12:02] >>862 競争力。 865 名前：858 mailto:sage [04/10/24 13:13:24] >>859 漏れはいいメンバーになるYO 頑張るから入れてください 866 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:18:14] >>864 わけわからん 867 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:20:53] >>853 そもそもアメリカってそんなにEAだらけなのかな？ ひょっとしてレアな特殊事例を一般論として売り込まれるだけなんじゃ… 868 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:21:18] >>849 > ttp://nekop.programmers.jp/diary/?date=20041024 > これ読んだらEAは俺には縁のない世界だと思った。 ttp://d.hatena.ne.jp/habuakihiro/20041024#1098575922 はぶ氏も似たようなこと言ってる。 869 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:24:51] >>844 手続き指向に対してオブジェクト指向はいわば「データ指向」といえる。 オブジェクトのデータ構造はオブジェクト内に隠蔽されているが、手続き自身も オブジェクト内に隠蔽されているので、この手続きの再利用性が低くなる。 オブジェクト内の手続きを再利用する方法として継承を使うことができるが、 継承はクラス間の関連としては大変密な結合であり、単に手続きを再利用する ためだけに派生クラスを作成して実装を継承するのは結合度が強くなって しまうためよくない。 これらに対して、ジェネリック・プログラミングは「アルゴリズム指向」である。 これは、手続きの再利用性を求めて単に手続き指向の世界に回帰したように 見えるかもしれないが、そうではない。 ジェネリック・プログラミングにおける手続き(アルゴリズム)は、手続き指向の 手続きと違い、データの構造は知る必要がない。そのアルゴリズムを実装する ために必要な操作をオブジェクトから開示してもらうことにより処理を行う。 従って、あるアルゴリズム(手続き)に処理してもらうために必要な最小限の インタフェースをデータ型から抽出することが、ジェネリックプログラミングを 実現する第一歩となる。 870 名前：デフォルトの名無しさん [04/10/24 13:41:33] >>844 >結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。 ウィンドウシステムを扱うライブラリが非ＯＯだったときのことを考えれ。 871 名前：デフォルトの名無しさん [04/10/24 13:48:36] >>890 >587 >顧客クラスにパスワード変更メソッド付けるなんてアフォ つまり、データはハッシュマップなりで適当なもので表現して （実際、形宣言無し言語ではこれが常識）、それを扱うプログラムをクラスとして 定義するのがいいってことで、パスワード変更クラス、ユーザ名変更クラスを作るのは よい設計ってことやね。（経験積んだ人がシンプルに作ろうとしたら結局そうなる、いうまでもなく） 872 名前：デフォルトの名無しさん [04/10/24 13:52:04] >>871 データを一番シンプルに扱えるのがハッシュマップである以上、 無意味なキャストが頻繁に起こるJavaは業務アプリ作りには向いてない。 型宣言が無い言語のほうが業務アプリ作りには向いてる、Javaは向いてない っていう仮説はどうかな。 873 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:52:20] >869 オブジェクト指向は学術的には"手続による抽象化"であって、 抽象データ型(ADT)より手続に近いっていう話しだが 漏れにはその区別がどうも良く解らない 結局メッセージパッシングしてメソッド(==手続)呼び出してるだけって事なのかな。 ADTとはどう違うんだ。 874 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:53:31] 「こんなデータと処理の分離は嫌だ」シリーズを考えてみよう。 データと処理が分離されたCollection API ｺﾜｰｲ…。 875 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:56:18] ttp://sumim.no-ip.com:8080/wiki/710 視点の違い 876 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:56:32] データと処理が分離されたデータベース 877 名前：デフォルトの名無しさん [04/10/24 13:58:43] >>873 結局メソッドを呼び出すのがＯＯ。 オブジェクト指向の肝はポリモーフィズムで、 それでシステムをシンプル（柔軟性と、メンテナンス性を保つ）に表現 するっていう、ただそれだけ。 878 名前：デフォルトの名無しさん [04/10/24 13:59:31] >>872 Java5で解決ですが。。 879 名前：デフォルトの名無しさん [04/10/24 14:02:18] >>878 漏れには解決しているようにはとても見えへんのよ 880 名前：デフォルトの名無しさん mailto:sage [04/10/24 14:13:32] だれか、>>863について斬ってくれ。 881 名前：デフォルトの名無しさん [04/10/24 14:15:50] ORマッピングで継承って一体なんなんだ？　意味不明。 データはデータ。処理は処理だろ？ 882 名前：デフォルトの名無しさん [04/10/24 14:20:09] 処理の切り替えって、やりたきゃやればいいんじゃないの？ 883 名前：デフォルトの名無しさん mailto:sage [04/10/24 14:36:40] >>881 こういうののことでつ。 ttp://objectstyle.org/cayenne/modelerguide/modeling-object-layer/inheritance.html 884 名前：デフォルトの名無しさん [04/10/24 14:44:58] 処理の切り替えが沢山あるなら、 処理できる？ Handler#canHandling(data) 処理が重複したときの優先順位を返す Handler#priority, 処理する Handler#handle(data) みたいのを作って Manager#addHandler(handler) てなことやると分離できるな。これが適切なときもあるにはあるだろう 885 名前：デフォルトの名無しさん mailto:sage [04/10/24 14:54:13] >>871 >>872 そんなお前らはDbUtilsでも使ってろ。 まあ、>>872の後半はわりといいポイントをついてるような気がするんだが。 886 名前：デフォルトの名無しさん mailto:sage [04/10/24 15:57:59] Ruby最高ってことでFA 887 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:11:53] >>845 「薄いサービス層」の薄いって何のことだか分かって言ってる？ 何でツッコミが入ってないのか分からんけど。 >>884 そこまでやって分離したがる理由が分からない。 素直にO/RMapper使って解決できる問題であれば、そうすべきだろう。 ↑でも適材適所って言ってるだろ？ 888 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:13:34] >>887 「分離可能」といってるだけじゃないの？ 「適切な場合もあるにはあるだろう」だし。 889 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:15:11] >>888 だね。最後の方良く読んでなかった。ｽﾏｿ。 890 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:16:15] >>871 890ゲット！！ データはマップで持っておくのがいいかもっていうか、だめっていうか、いいね。 思ってもいないことを言ってみる。 891 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:21:15] ER図と照らし合わせながらでしか解読できんコードになるぞ。 892 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:35:46] なんか急激にしょぼいスレに戻りましたね。 ＞＞８８７ blogでは、その後ろに「ドメインモデル」或いは「リッチな業務ロジック」が続くと 書いてあります。ドメイン層ですね。 プレゼンテーション層から最初に呼ばれ、適切なドメイン層の処理を呼び出す ステートレスなクラスというのは、薄いサービス層に他ならないのでは？ ファウラーではなくEric Evansですが。 間違っていたらご教授願います。 以下 ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel より引用 アプリケーション層（サービス層のこと）：ソフトウェアが何をしなければいけないかを 定義し、ドメインオブジェクトに対して、問題を解決するよう命令する。この層の役割は ビジネス活動にとって重要であり、別のシステムのアプリケーション層とやり取りをする のにも必要である。この層は薄く保たれている。ビジネスルールやナレッジを含むもの ではないが、その下の層にあるドメインオブジェクトの協調関係に対して、タスクを調整 したり、仕事を委譲したりしている。これはビジネスの状況を反映するものではないが、 ユーザーやプログラムの進捗状況を反映することは出来る。 ドメイン層（モデル層）：ビジネス、ビジネスの状況に関わる情報、ビジネスルールに ついての概念を表す。ビジネスの状況を反映する情報は、ここで管理・使用される。 技術的には、その情報はインフラ側でストアされている。この層はビジネスソフトウェアの 魂である。 ここでのキーポイントは、サービス層は薄い、という点です（キーとなるロジックは ドメイン層に置かれています）。 893 名前：887 mailto:sage [04/10/24 16:53:26] >>892 なんだ、わかってたのね。 つまり、 [ドメインモデル] UI層 ⇒ 薄いサービス層 ⇒ ドメインモデル ⇒ データアクセス層 [リッチな業務ロジックモデル] UI層 ⇒ 薄いサービス層 ⇒ リッチな業務ロジックモデル ⇒ データアクセス層 こういうことなら、あのコンテキストで「薄いサービス層」って 言葉が出てくるのも納得できる。 ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が あまり見出せない。 分散環境でも無い限り、ドメインモデルでの薄いサービス層はリッチな業務ロジックモデルに 対応するって方が自然な気がするんだけど、どうでしょう。 894 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:55:07] >>892 > なんか急激にしょぼいスレに戻りましたね。 禿げ胴!! S2とも、くーすとも関係なくなった。しかもレベル低い。 895 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:58:47] OO厨なんてこんなもん 896 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:32:46] と、OOがわからなかったCプログラマーが申しております。 897 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:42:11] フォーラムみたいなのがあればなぁって 誰かが言ってたけど、ホントにあったほうがいいような気がする。 2chだとまともに議論にならんことも多いから。 898 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:45:23] >>893 >ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が >あまり見出せない。 プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？ ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。 899 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:55:05] >>898 > プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？ > ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。 素直に考えるとそうなんだけど、実際にファサードが必要になる状況ってそんなに無いよね？ だからそれをスタンダードにしまうのにはちょっと違和感を感じる。 ステートレスなサービス層が具体的に何を想定しているのか、 ひがさん本人に聞くのが一番早いんだろうけど。まだちょっとわかり辛いかな。 900 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:58:36] ファサードが必要になる状況というか、 普通にデザインしてたらそこはそうするだろ。 EJBを使ったことのある人間なら。 StatelessSessionBeanでサービスを作る必要性がわかる人間なら。。 StrutsのActionクラスに業務ロジックを書くことにためらいがある人間なら。 901 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:03:10] >>900 StrutsのActionから直接ステートレスな業務ロジック呼び出すのと、 間に無駄なファサード挟むことの違いを言ってるんだが。 902 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:03:41] ひがさんは「プレゼンテーションから呼び出す（業務ロジックの）メソッドは１つだけ」 と仰ってます。 分散環境でなくとも、各層間のインターフェースはシンプルにしておくのは有効だと思います。 プレゼンテーション層は、StrutsやTapestryなどのフレームワークに密接に依存するため、 テストがしにくいからです。また、各層での平行開発も行えるようになります。 903 名前：910 mailto:sage [04/10/24 18:12:38] 説明が悪いのかな。 900氏の言うように「普通にデザインしてたら」、 StrutsのActionなどに提供される業務ロジックインターフェースの メソッドは１つだけになる。で、複数必要になるような状況ではファサード挟む。 でも、複数呼び出しが必要になるような状況(つまりファサードが必要になる状況)ってそんなに多いか？ 多くないならいきなりActionから業務ロジックのインターフェースで提供されてる メソッド呼び出すほうが素直じゃないの？って思ったんですよ。 904 名前：デフォルトの名無しさん [04/10/24 18:13:33] >>869 それって、DB毎にアクセス用サブルーチン作って、手続き型してるだけでわ。 905 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:18:01] >>903 必要ないでしょ。ケースバイケース。 906 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:28:51] かつて、ほぼ並行して2つのやり方をしたプロジェクトがありました。 あるプロジェクトでは、人に業務機能を割りあてました。 データベース設計はある一人が担当し、 他の各人がデータベース―EJB―Web層(Struts)、HTMLをすべて担当しました。 全員のスキルはまちまちでした。 みんな徹夜を続けながら、死ぬ思いで納品しました。 みんなのスキルは、ある程度のレベルまで上昇しました。 メンバに感想を聞いてみると「設計としては汚い。楽なことはなかった」とのことでした。 あるプロジェクトでは、人にシステムの機能を割りあてました。 データベース設計、EJB、Web層(Struts)、HTMLを、それぞれが担当しました。 全員のスキルはまちまちでした。 みんな徹夜を続けながら、死ぬ思いで納品しました。 みんなのスキルは、担当場所についてのみかなりのレベルまで上昇しました。 メンバに感想を聞いてみると「綺麗な設計になってる。実装作業は楽だった」とのことでした。 誰が幸せなのでしょう。 907 名前：デフォルトの名無しさん mailto:sage [04/10/24 19:22:17] >>906 > 誰が幸せなのでしょう。 俺俺！ 908 名前：デフォルトの名無しさん mailto:sage [04/10/24 19:25:02] 綺麗な設計を手に入れたお客さん。 909 名前：デフォルトの名無しさん mailto:sage [04/10/24 19:34:41] >>897 S2で作れ！期待してます！ 910 名前：デフォルトの名無しさん mailto:sage [04/10/24 20:12:08] >>909 その前にくーすで設計だろ？ 911 名前：デフォルトの名無しさん [04/10/24 20:32:39] そうこうしている間に.Netが主流に。 912 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:01:43] Ruby.netが最強だと。 913 名前：デフォルトの名無しさん [04/10/24 21:05:27] 薄いサービス層 ⇒ ドメインモデル とか 薄いサービス層 ⇒ リッチな業務ロジックモデル これ、何いうてるんですかね。 どうしてもプラットフォーム／言語非依存にしたくてっていう気分でもならないかぎり、 この２つを分ける理由は謎。 914 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:09:50] >>913 ...これまでの流れ、分かってます？ 915 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:21:37] Ruby最強・・・かな？ 916 名前：デフォルトの名無しさん [04/10/24 21:21:50] 正直、ドメインモデル　リッチな業務ロジックモデル の違いも分からん 藻前ら難しく考えすぎだ 917 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:41:30] >> 916 お前は、きっちり分割されたシステムの一部を仕様通りに 月１５万でコーディングすればいいだけだから、気にするな。 918 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:56:07] >>917 月１５万でコーディングしてくれるの？ だったらうちで働いてよ。 919 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:58:55] 2人日の価格で1人月か。お徳だ。うちにぜひこないか 920 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:14:18] うほっ！ か　か　な　い　か　？ 921 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:16:11] >>919 あんたのところ高すぎ。 コーダーで月１５０万かよ！ うちの倍とってるじゃん。。。 922 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:16:47] じゃあRubyのDIコンテナに期待しよう あるのかな 923 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:33:31] そろそろ新スレ立ててもいいんでない? 924 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:38:28] 今の流れだと、次スレは必要なさそう。 925 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:39:14] 盛り上がっているところに水を指すのは申し訳ないが 正直S2ネタが殆どないのにS2の名前で新スレ立てる 意味がないような気ガス。どう見ても単なるOOネタ。 こっちのスレのほうが適している気がする 【OO?】オブジェクトオリエンテッド総合【非OO？】 pc5.2ch.net/test/read.cgi/tech/1041658161/l50 926 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:45:08] そうだな。 PoEAAのスレでも立てるほうがよっぽど盛り上がるんじゃないか？ S2ネタはS2JSFｷﾎﾞﾝﾇばっかりだしｗ 927 名前：デフォルトの名無しさん [04/10/24 22:52:43] >>917 >お前は、きっちり分割されたシステムの一部を仕様通り そんなシステムあるわけないだろボーケー 928 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:02:45] >> 927 まず日本語から勉強しましょうね〜。 929 名前：805 [04/10/24 23:05:07] >Statelessな場合は、Ma、Mbに依存関係はありません、と以前書いたのですが、 >実は間違ってますね。m(_ _)m >ここでいっている依存関係とは、呼び出し順序の依存関係です。 > >状態Sが更新されない場合は、確かにMa、Mbには依存関係はありません。 >しかし、MaでSが更新され、MbがMaで更新されたことをあてにしている場合、 >MbはMaに依存しているということになります。 Mbが依存しているのは Maじゃなくて、ステートSなんだと思うんだよね。 Maの呼び出しによって、ステートS => ステートSa となるとして、 Mbが当てにしているのは「事前のMaの呼び出し」ではなくて 「Ma呼び出しによってセットされるステートSa」なんじゃないかな? よって、ステートSを外に出したところで MbがステートSaを前提にしていることには なんら変わりない、ステートSを中に置こうと外に出そうと何も変わりはない、と。 930 名前：805 mailto:sage [04/10/24 23:06:15] >>929 ごめん、ソースは d.hatena.ne.jp/higayasuo/20041024#1098580377 ね。 931 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:13:31] OOネタはS2というかくーすから転がっていって ひがさんのブログでの反応とあいまって こうなったんで、このままここでいいよ。 932 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:16:36] 普通はスレ違いなんだがな。 このスレには優しい人が多いということか。 933 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:19:16] このスレは次から「国産DIコンテナSeasarの人たちv2」という名前にするべきだ。 そうすれば、今までのこともスレ違いではなくなる。 934 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:20:03] ダサッ！ 935 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:46:17] >>929 　おバカな漏れからみると、ステートを外出しに出来れば、例えばセッションの方を ステートフルにしてサービス（ロジック）オブジェクトはステートレスにしてプーリング したりできて便利になるような気がするんだけど。 もちろんこれは（現実に広い応用はあっても）トイ・アプリケーションレベルの簡単な ロジックの場合だけであって、複雑なステートを持つ UI セントリックなアプリケーションが 必要な場合などにはステートを外だしにすることによって情報隠蔽の逆を行ってしまう 可能性もあるわけだけれども (そういう部分をクライアント側に押し付けられるなら有効か・・・)。 936 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:53:55] 比嘉氏はStateはPresentation層に持つって言ってるので>>935は同じ事を言ってる気がするのだが 937 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:00:23] >>933-934 「S2のソナタ」にでもしておけばよかろう 正直漏れは次スレいらん気がしてるが 938 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:03:48] >933 人たちというか、そもそもS2ってそれ自体で何が出来るというものでもなくて 開発を支援する（＝楽にする）ってな発想だと思うので、その流れでくーすときて じゃ、既存のOOPとか設計ってどうなのよ？って話になってもおかしくないと思われ。 >936 Flash（Flexもだが）やら.NetのSmart ClientみたいなRIA（リッチかどうかはさておき）のWebアプリなら Presentation層で保持するのでやり易いだろう。 HTMLのブラウザベースのWebアプリだと小細工をせんといかんのだけど 939 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:13:28] >> 938 そこでS2JSFですよ。 940 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:15:06] >938 おれ今までsessionとかrequestってプレゼン側領域だと思って 状態の管理にも使ってたんだけど、世間じゃ違うのかな。 小細工ってどんなの？ 941 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:19:59] OOPの話がしたければ、それなりのスレへ。 新しい別のスレをたてる必要はない。 そこではSeasarの話はスレ違いだがね。 Seasarの話、くーすの話、ひがさんはぶさんの話がしたければ、それなりのタイトルのスレ建てれ。 942 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:25:20] 禿同 長文多いしage多いしスレ違い多いし ハッキリ言ってウザイ 943 名前：805 mailto:sage [04/10/25 00:26:53] >>935 > >>929 > 　おバカな漏れからみると、ステートを外出しに出来れば、例えばセッションの方を > ステートフルにしてサービス（ロジック）オブジェクトはステートレスにしてプーリング > したりできて便利になるような気がするんだけど。 ドメインロジックを含んだクラスをステートレスにすると、 SmalltalkBestPracticePatternsで挙げられているパターンや、リファクタリングの テクニックの大半が使えなくなります。 # 数少ない経験に基づいてるので嘘かもしれませんが。 そんな強烈なデメリットを負ってまでステートレスにして得られるものが、 「サービスオブジェクトのプーリング」というのは、 *個人的には*、割に合わないと感じています。 # もちろん、必然性のあるステートレス化には賛成ですが。 944 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:29:27] 「ダイコン時代のスレ」でいいんじゃない？ 945 名前：デフォルトの名無しさん [04/10/25 00:34:31] もう分かりきってることだと思うけど、抽象的過ぎてかみ合わない。 アプリケーション毎に違うんだよ。どういうパターンがいいかなんて。 もう漏れは飽きた。寝る。 946 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:35:59] seasarの話、くーすの話、OOの話、業務の話、 全てはひが様のもとへ、じゃ。 よってこのまま続行。 つか、ここの住人が杓子定規なスレタイ重視によって 分散してしまうのは、しじょーにもったいなく思いまーす。 947 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:38:14] では違うところに集うが良かろう。 でなければまずはsage進行で頼む。 948 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:48:11] >943 Cookieゴソゴソしたり、HTTP越しにSessionオブジェクトを弄ぶのはなんか不健康な気がしたので。 勿論、仕方無しにPresentationの役割と思ってやってるんだけど >941、942 見てるからには何らかの関心があると思うんだが、じゃ、どんな話題なら良いのよ？ 大半の香具師はアンチうざいのでsage進行だと思うしさあ。 とにもかくにも嫌なら見ることねえじゃん。君の人生、時間は限られてるんだからさあ。 >944、946 禿同、けど’ダイコン時代’ってキーワードはまだ認知されてないのでスレタイにはどうかなあ。 J2EEに疲れてませんかってなのはどう？けど、アンチJavaの呼び水になるからなあ。 あ、ちなみに自分は.NetもJavaでも楽に儲かりゃどっちでもいいし、どっちも実務でやってるので 宗教論争ならくだらん。 949 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:59:23] しょっちゅうageてるじゃねえか。 上にくりゃ見えちまうだろうが。 sageくらい覚えろよ。 あと変なポインタ振るな。 長々書き込むな。 正直このスレの住人ウザイ。 2ちゃんにくんな。 950 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:10:48] J2EEに疲れてませんか、ではくーすの話はスレ違いだね。 951 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:29:23] >>949 N速にでも逝って２ちゃんらしさを存分に味わっとけ。 次スレはsage進行でマターリと語りたいね。 952 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:30:13] >>945みたいなアゲにげするやつがいるからねぇ。 953 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:32:45] じゃ、次はS2JSFでてからってことで解散。 954 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:33:08] 分析から実装まで 開発を見つめるDICON 955 名前：デフォルトの名無しさん [04/10/25 02:17:15] もはや広告が撲滅された以上、sageと入れるのは馬鹿。 そもそも同人板のヲタ女達が始めた風習だし。 956 名前：デフォルトの名無しさん mailto:sage [04/10/25 02:24:08] 風習の起源とか目的とか、どうでもいいだろうが。 いまそういう風習なんだから。 957 名前：デフォルトの名無しさん mailto:sage [04/10/25 02:38:26] Stateless化することで見込まれているメリットの肝は、実は分業の徹底では ないかと思う。設計段階でDomain Modelを完璧に固めるのは困難だし、 かと言ってXPみたいにボトムアップでぐりぐり設計が変わるのを許容して しまうと、チームに馬鹿が一人いるだけでリーダーは安心して眠れない。 そしてある程度の規模の仕事となるとだいたい馬鹿のほうが多数派になって しまうのが悲しい現状だ。 そこで「馬鹿はinterfaceをいじっちゃいけない」という制約が登場。 958 名前：デフォルトの名無しさん mailto:sage [04/10/25 08:06:05] 次スレ立てるんなら>>1はガイドラインよろ sageでﾏﾀｰﾘとか個人名晒した誹謗中傷はなしとかそういうのな せっかくいい感じになってきたのでﾀﾉﾑ 959 名前：デフォルトの名無しさん [04/10/25 11:28:42] >>957 ペアプログラミングと腐らずコミュニケーション続けることしか解決の道は無い 960 名前：デフォルトの名無しさん mailto:sage [04/10/26 00:49:26] このままのスレでいいじゃん。 961 名前：デフォルトの名無しさん mailto:sage [04/10/26 01:14:57] スレタイに「くーす」要追加。 962 名前：デフォルトの名無しさん mailto:sage [04/10/27 05:30:18] AVAYAのロゴがAYAYAに見えるオレは、なにかに毒されていますか？ 963 名前：デフォルトの名無しさん mailto:sage [04/10/27 17:20:16] 次スレはS2JSFが完成してからだね。 964 名前：デフォルトの名無しさん mailto:sage [04/10/27 20:13:24] 関係ないけど、サンプルのHTMLにmetaタグでcontent-type入れるのはかっこ悪いからやめたほうがいいと思われ。 S2JSFだとContentTypeヘッダーを送れないというのなら別だけど。 965 名前：デフォルトの名無しさん mailto:sage [04/10/27 20:15:46] 最も単純な例がXHTMLだとしたら、普通のHTMLは使えないのかと思ってしまう。 966 名前：デフォルトの名無しさん mailto:sage [04/10/27 20:57:39] >>964 なんでかっこわるいの？ 967 名前：デフォルトの名無しさん mailto:sage [04/10/27 22:00:22] ContentTypeヘッダーを送るならmetaタグ入れないほうがいいことになってるから。 968 名前：デフォルトの名無しさん mailto:sage [04/10/27 22:11:17] >>967 それがかっこわるい理由か？ 969 名前：デフォルトの名無しさん mailto:sage [04/10/27 22:59:04] >>967 RFC&W3Cﾏﾝｾｰなんだね。 IEおよびNetscapeの特定のバージョン（忘れた）でヘッダだけでは 文字化けする場合があるバグありバージョンがある。 客に文字化けするんだがって言われたらブラウザのバグですって言うの？ まー、客から見たら文字化けしないサイトもあるんだから対応しろボケって なると思うけど。 970 名前：デフォルトの名無しさん [04/10/27 23:13:06] 次スレ立てました。 国産DIコンテナSeaserとくーす その2 pc5.2ch.net/test/read.cgi/tech/1098885253/ 971 名前：デフォルトの名無しさん mailto:sage [04/10/28 01:05:52] 技術屋がかっこつけようとすると お客さんの価値観とは合わなくなる事が多く思いますが よい例でしょうかね。 俺も出来る事なら存分にかっこつけてみたいわ。 972 名前：デフォルトの名無しさん mailto:sage [04/10/28 02:20:21] 969が正解でしたね。 ひがさんてば、こんな事にまで答えてくれるとは・・・・。 973 名前：デフォルトの名無しさん mailto:sage [04/10/29 00:38:27] >>972 俺は >>571 です。 ここはエセ技術屋が多いインターネッツですね。 うんこばかりだな。 974 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:42:43] はいはい あなたみたいにみんなから尊敬される素晴らしい技 術屋さんには見るもの全てがうんこにしか見えない んだろうからここに来なくてもいいよ 975 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:53:25] エセねらーがｲｿﾀｰﾈｯﾂとか書いてんじゃねえよ（藁 976 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:59:02] お，半角SPACEたんｷﾀｰ(AA略) 相変わらずの粘着ぶりでつね！ 977 名前：デフォルトの名無しさん mailto:sage [04/10/29 02:00:22] metaタグうんぬん言ってた人が 571ってこと？ まあmetaタグがどうのってこだわりがあって そういうのが技術力だって価値観も確かにアリだと思うけど そういう価値観の人ならseasarもくーすも要らないんじゃないかな。 978 名前：デフォルトの名無しさん mailto:sage [04/10/29 02:15:26] 571 たんはひがたんよりも自分のほうが優秀なのにひがたんのほうが目立っているので嫉妬してるのでつ ASM も meta もせっかく教えてやってるのに聞いてくれないのでひがたんはうんこな香具師だと思ってるのでつ 要するに 571 たんはひがたんのうんこが食べたいのでつ 頑張ってイソターネッツとか書いてる 571 たんは本当はいい人なのでつ 979 名前：デフォルトの名無しさん mailto:sage [04/10/29 23:50:16] ひがさんはいつ仕事してるんだろうか 980 名前：デフォルトの名無しさん mailto:sage [04/10/30 17:02:00] タペのサンプルの動かし方がわからん。 981 名前：デフォルトの名無しさん [04/10/31 13:23:24] 顧客満足＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞(超えられない壁)＞＞＞＞＞＞＞＞＞＞＞＞＞＞W3C,RFC 982 名前：デフォルトの名無しさん mailto:sage [04/10/31 17:26:28] 長期間の動作保障＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞(超えられない壁)＞＞＞＞＞＞＞＞＞＞＞＞＞＞クイックハック 983 名前：デフォルトの名無しさん mailto:sage [04/10/31 21:52:57] ベンダの短期的な思惑＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞(超えられない壁)＞＞＞＞＞＞＞＞＞＞＞＞＞＞長期間の動作保障 984 名前：デフォルトの名無しさん [04/10/31 23:28:25] 長期の動作保証とクリックハックは往々にして両立する罠 例えば、metaタグでcontent-type入れるのとか。 985 名前：デフォルトの名無しさん mailto:sage [04/10/31 23:31:04] ×リ ○ィ 986 名前：デフォルトの名無しさん mailto:sage [04/11/01 23:58:53] ちゃんとスレ埋め立てようぜ 次スレばっかり伸びてるじゃねえか 987 名前：デフォルトの名無しさん mailto:sage [04/11/02 00:52:51] いっそ次スレのほうが先に埋まるのを見届けるとか 988 名前：デフォルトの名無しさん mailto:sage [04/11/02 05:42:06] 980も超えてるし、そのうち勝手に落ちるよ。 989 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:09:12] せっかくだからしりとりでもしようぜ。まずは俺からな。 シーサー 次！ 990 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:27:24] サッシ 991 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:47:24] 示唆 992 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:55:37] サラシ 993 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:57:10] シーサー 994 名前：デフォルトの名無しさん mailto:sage [04/11/02 15:01:49] >>993 サナダムシ 995 名前：デフォルトの名無しさん mailto:sage [04/11/02 15:51:14] 視差 996 名前：デフォルトの名無しさん mailto:sage [04/11/02 15:55:14] 桟橋 997 名前：デフォルトの名無しさん mailto:sage [04/11/02 17:14:19] 審査 998 名前：デフォルトの名無しさん mailto:sage [04/11/02 17:18:16] 酒蒸し 999 名前：デフォルトの名無しさん mailto:sage [04/11/02 17:23:44] しにせ 1000 名前：デフォルトの名無しさん mailto:sage [04/11/02 17:24:23] せん 1001 名前：１００１ [Over 1000 Thread] このスレッドは１０００を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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