国産オープンソース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/ 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..

---

---

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

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