国産オープンソースDIコンテナSeasar V2(S2)

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 16:10 / Filesize : 285 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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/
263 名前：デフォルトの名無しさん mailto:sage [04/10/04 07:03:23]: >>262
もう記述は外れてるからどうこういってもしかたないんだけど、「初心者にもやさしい」というニュアンスだったような気がするんだけど。
「ドキュメントが豊富です」と声高に叫ぶほどドキュメントが充実してたわけでもないし。
要は、宣伝文句と実情が異なってたからどうよ、と思ってたわけさ。
264 名前：デフォルトの名無しさん mailto:sage [04/10/04 07:14:34]: >>263
J2EEとコンテナ、アスペクトの初心者には充分やさしいと思う。

さすがにJava初心者にはやさしくない。ていうか、インターフェースでプログラミングすると
いうことをSQLできます、COBOLやってました。という人々に理解してもらうのは、すげー難しいぞ（W
265 名前：デフォルトの名無しさん mailto:sage [04/10/04 07:30:21]: まあ、問題は初心者っていったときに、なにか勉強しはじめた人のことではなくて「初心者という生き物」のことを指してしまうことがあるからなぁ。
宣伝文句と実情が異なってたときに、オレとしては実情の方をあわせて「これでどうよ？」となってほしかったのだけど、宣伝の方が取り下げられてしまったのは残念だ。
マンパワーの問題もあるだろうし、しかたないのだろうけど。
実情が伴ってきたときに、またあの宣伝文句を掲げてくれれば、と思う。
266 名前：デフォルトの名無しさん mailto:sage [04/10/04 10:06:16]: >>255
ここに実名で書き込むヤシはいないだろ。
267 名前：デフォルトの名無しさん mailto:sage [04/10/04 10:10:42]: >>265
マンパワーの問題というよりも、ここでの粘着振りに
ひが氏がうんざりしちゃったんじゃないのかな
コンテナのドキュメントが急に書き換わったり
意地になってた気がする。
268 名前：羽生 mailto:sage [04/10/04 11:07:35]: 羽生と申します。2chで本名で書くのもどうかと思いますけど、けじめはつけておきます。
まず、ここに書き込まない理由は、

１．私は長文になってしまうので「長文ウゼー」って言われるからです。
改行が多すぎて書き込み出来ません、ともなります。

２．誰がどの書き込みをしたのかわからないので、脊髄反射的な会話に
しかならないからです。ハンドル名であっても一貫していれば、書き込みの
流れから行間を読むことで解釈のずれを埋める工夫が出来ますが、
そういう機能がないため「書き手の気持ち」を類推することが出来ず、
結果として言葉尻だけを取り上げることが多いからです。
これは、「私には」しんどいことです。

３．追いかけるのが大変だからというのもあります。自分の発言にレスがあったら、
きちんと返さなければという強迫観念があります。blogの場合は、あくまでも「コメント」ですので、
それに対してレスをしなければという気持ちは大らかでいられるのですが、
掲示板などだと常にウォッチしなければということで、日常に入り込んでしまいます。
忙しいときにはそれが苦痛になるので、控えています。これはMLもそうです。

４．自分が発する言葉は自分の心からしか出ません。ですから匿名であっても
責任が生じます。しかしトリップをわざわざ取ったりなど、仕組みとして「自分の責任」を
表明するのが面倒です（取ったこと無いし取り方を調べるのも面倒^^;）。
ですからここで自分の名前によって書いても、騙りと思われたりする可能性を考えると
blogのほうが確実だと考えています。

以上です。その上で、もう少し書きたいと思います。
269 名前：羽生 mailto:sage [04/10/04 11:09:45]: まず、「優しさ」ということを掲げることについては、誰も反対はしないと考えています。
要点は、これを「理念・目標」と捉えるか、「宣伝」と捉えるか、でしょう。

では、これについて、
「私は宣伝と受け止めた。ついては宣伝に反している。改めるべきだ」
と考えた場合に、意味のある形につながるように取れる行動として、
例えば次のようなことがあるのではないか、と思うのです。

「優しさ、と書いているが、自分には優しさが足りてないように感じる。
ついては、まず、こういうドキュメントを追加してみてはどうだろうか。」　

そして、ほんの少しでも叩き台として出していただければ、それが呼び水となります。
ゼロから1への最初の一歩が大変なのです。マンパワーの問題もありますが、
そもそもご指摘があったように、知ってしまっている人間にとっては、ここが足りてないのか
という最初の気付きは難しいものです。

せっかくオープンソースであり、しかも英語圏に比べれば圧倒的に身近な国産のプロジェクトなのですから、
前向きな小さなはじめの一歩をいただければと思うのです。これをMLに投げてもらうだけでも随分と有効です。
MLも別にyahooメールで書いてもらっても構わないのです。同じ問題意識の発露であった場合に、
少なくとも、ここで汚い言葉でののしるよりもどれだけ有効で、どれだけ他の人の役に立つでしょう。

ですから、私はここで文句を言ってるだけというのは、実はこういう問題意識を持ってのことではなく、
それはポーズであって、実は別の感情が潜んでいるのではないか、という風に感じてしまいます。

このスレに書いたことでさえ、ひがさんはちゃんと受け止めて反映しています。
JavaDocプロジェクトも徐々にですが着実に進んでいるのも、例えばからさわぎで
「2chでも指摘されてますが、JavaDocいる人ってどれくらいいます？」というようなやり取りをして、
そこからちゃんと取り組みが始まっています。拒絶はしていません。
ですから、もっと誰もが受け入れやすい形でご提案いただければすごく嬉しいです。
270 名前：羽生 mailto:sage [04/10/04 11:11:34]: 引き続きですみません。

さて、私はこのスレの位置付けというのは初心者にとって大きいため、
ここで不当に貶されるのは、S2へのアンチマーケティングをされていると考えています。
というのは、Seasarで検索するとこのスレがヒットします。知識のないひと（スキルがない
のとは別です）が、ここを見てどう思うか、ということを考えると、必ずしも実情が伝わる
とは思えないのです。

というのは、「優しさ」という言葉尻とその周辺のことばかりが取り沙汰されていますが、
では技術的にどうか、などのことは全然触れられていません。端的に言えば、ひがさんや
取り巻き（この表現の意図もよくわかりませんが）の人格に対する話しかないのです。
ということは、人格に関する情報だけで技術水準を判断されてしまいかねません。

つまり「優しさ」の守り手たらんとしている誰か（誰か、としかいいようがありません）の
発言が結果として、「優しさを必要としている人」の無知識につけ込んでいるようにも感じます。

私たちがやっていることが、全て必要にして十分なレベルにあるなどとは到底いえませんが、
残念ながら客観的に評価されているようには思えません。
こういう部分は優れている、こういう部分はもっと改善が必要だ、というように、要素ごとに
きちんと評価して総合判断を提示するのが、技術者の基本ではないかと私は考えています。

その評価結果が厳しいものであってもそれは謙虚に受け止めてさらに取り組みます。
その意味において、残念ながら非常に一方的な負の感情のみで書かれているようにしか
見えないものが多いのです。ここでまた、S2そのものに対するのではなく別の感情が潜んで
いるのではないかと考えたりもします。
271 名前：羽生 mailto:sage [04/10/04 11:16:01]: とりあえず最後です。

このようなことを踏まえた上で、他人を「うんこ」だの何だのという言葉を使うというのはどうなんですか？
実名で「これを書いたのは私です」と胸を張って公の場でいえますか？　いえるのであれば結構です。
是非、私と会いましょう。いえないのであれば、それは後ろめたいという気持ちを持っているのです。
後ろめたさを自分で作って抱え込んでどうするのですか。匿名であろうとなかろうと、言葉は自分の心からでるものなのです。
その負の感情をなだめようとして匿名でさらに汚い言葉を使っても、それは悪循環に陥るだけです。

その負の感情の源泉が、Seasarプロジェクトの不出来さに起因するのであれば、わざわざ自分の気持ちを
痛めつけるのではなく、お持ちのスキルとその問題意識を良い方向に発揮してください。歓迎いたします。
もし、Seasarプロジェクトに起因しているのでないなら、それは申し訳ありませんが八つ当たりに過ぎません。
自分の心で解決していくことです。ただそれも、例えばからさわぎのような場所で、普段会わないような
広い範囲の方々と話をするだけでも、何かが見えてくるかもしれません。

実際、からさわぎはJavaは殆どわからないという方も多く参加されています。
そして宴会の場で、技術ではないことでも意見交換が出来て非常に役に立ったという感想を
お持ちの方も多くいらっしゃいます。

「来いや」は確かに言葉が乱暴かもしれませんが、本心です。多くの方が前向きに（S2に対して、ではなくて、
自分の将来に対して）取り組んでいる場に触れるだけでも全然気持ちが変わります。
私も別に年中元気なわけではありません。しかし皆さんとお会いすると元気をいただけます。
私も少しでも皆さんの元気のお役に立てるようになりたいと思ってます。
是非、お会いしましょう。前向きなケンカは必ず第3の素敵なアイディアを生み出します。別にケンカしなくてもいいんですけどね(^^)
今後ともS2およびSeasarプロジェクトへの叱咤激励をよろしくお願いいたします＞all

尚、やっぱり恐いので基本的にここでは書きません。2chで実名出すのはやっぱりドキドキしますよ（ｗ
272 名前：デフォルトの名無しさん mailto:sage [04/10/04 11:21:18]: 心配しなくても、実名の人に対して叩くほどの度胸はもちあわせておりませんよ。
トリップは適当に「羽生#seasar2004」みたいな#のあとに何かつけたらMD5かなんかの文字列になるだけなので、つけたほうがよさげです。
273 名前：デフォルトの名無しさん mailto:sage [04/10/04 11:26:44]: >>268-271
長文乙
274 名前：デフォルトの名無しさん mailto:sage [04/10/04 11:37:14]: 長文ｳｾﾞｰ
275 名前：デフォルトの名無しさん mailto:sage [04/10/04 11:40:58]: >>268-271
ﾈﾀﾆﾏｼﾞﾚ(ry
276 名前：デフォルトの名無しさん mailto:sage [04/10/04 11:49:43]: ハブカブアガル。微妙に。ちょっとだけ。
277 名前：デフォルトの名無しさん mailto:sage [04/10/04 13:18:10]: つか、
>>242
>>に自分が含まれていないって曲解してないか？
含まれてるのを前提として>>230を読み直しても、全然問題ないんだけど。
どう読んだら>>230がそういう曲解に見えるんだ！？

おまい、ひがさんの直下のプロジェクトやったことあるんだろ。
うらやましいなぁ。漏れは馬鹿にされるぐらいの勢いでケアしてもらった方が、安心できるけどな。

11月のからさわぎには絶対参加しよう。
278 名前：デフォルトの名無しさん mailto:sage [04/10/04 13:33:53]: >>277
はぶたんには、長文乙と伝えてくれ。
ひがたんには、うほっと(ry
279 名前：デフォルトの名無しさん mailto:sage [04/10/04 13:59:55]: それよりオマエら、S2のSがSpringのSとまぎらわしいと思ったことはないか？
オレはある。
プレフィックスはまぎらわしくないものにするべきだ。
ここは「夜の」をつけることにして大人の雰囲気を醸し出すようにするのはどうだろう？
つまり「S2Struts」「S2Hibernate」「S2Dao」を「夜のStruts」「夜のHibernate」「夜のDao」とするのだ。
これでSpringより大人な感じが伝わるのではないかと思う。
280 名前：デフォルトの名無しさん mailto:sage [04/10/04 15:13:19]: それは素敵な案だが少し淫靡な香りが漂う気がする。
そこで大衆の支持を得るために「冬の」をプレフィックスに
するというのはどうだろうか。春（Spring）に対抗するのだ。
「冬のStruts」「冬のHibernate」「冬のDao」とするのだ。
これでSpringよりも婦女子の人気もバッチリだろう。
281 名前：太田＠会社 mailto:oota_ken@hotmail.com [04/10/04 15:22:57]: 私はどちらかというと方法論者(Methodologist, 社内でRUPとかの推進をしています)で，その立場からSeasarを応援(期待)しています。

理想的には純粋なOO分析，設計でRUPなのですけど，スキルやリソース，コストの観点からは最低レベルの技術者でも一定の枠組みに従って開発できる仕組みと方法論が必要というのが現実のところです。Seasarと「くーす」はその一つの回答となっていると考えました。

こちらでもはぶさんのおっしゃられているようにもう少し建設的な意見があると良いかなと思うのですがどうでしょうか。
282 名前：デフォルトの名無しさん mailto:sage [04/10/04 15:40:36]: >>280
冬ソナかよ！
283 名前：デフォルトの名無しさん mailto:sage [04/10/04 16:20:52]: >>281

そんなに否定的な意見ばっかりかなぁ？

否定的意見に対する反論もあるし、後は読んだ人が自分で判断することなのでは。
284 名前：デフォルトの名無しさん mailto:sage [04/10/04 16:24:41]: >>281
匿名の場合、ネガティブな部分が大きく出て、建設的な意見は出にくいと思う。
ナイスアイデアは名乗ってから言いたいからな。
逆に、否定的な意見をここで拾えばよろしい。
>>279-280のようなとても建設的な意見もあるが。

っていうか笑わせるな。ひさびさ腹いたくなった。
285 名前：デフォルトの名無しさん mailto:sage [04/10/04 16:33:30]: 否定的なことを建設的に書けばいいんじゃないかな。
特定個人をとやかくいうんじゃなくて例えばJavaDocがない
とかならS2DaoのここだけでもJavaDoc書けやゴルァとかな。
何をやればもっと良くなるのかを指摘してやればいいんじゃないかな。
286 名前：デフォルトの名無しさん mailto:sage [04/10/04 17:00:55]: 全体的な指摘だと、こうするべきっていうのは書きにくいからなぁ。
現状サイトが貧弱だし、最初の入り口になるナビゲーションが非常にとぼしい。
最初になにをすればいいかわからないしな。
何度も言ってるけど、使ってみないとなにができるかわからない。
DIやAOPがなんであるかを知っていないと、使おうと思わないだろうな。
こういうのは、「ここをこう」みたいなヒトコトじゃ指摘できないんだよね。
ま、とりあえずホームページの体裁を整えて欲しい。

作者のブログとはいえプロダクトとはあまり関係ない話題を引用してきてどうこういうのはどうかと思うが。
287 名前：デフォルトの名無しさん mailto:sage [04/10/04 17:35:04]: トップページは何の更新もないし、タイムスタンプで新しくなったのがわかっても、ダウンロードするまで何がかわったかわからないし。
で、よくみたらブログにはちゃんと書いてあったりする。
288 名前：デフォルトの名無しさん mailto:sage [04/10/04 19:26:46]: >>287
それははなからブログをチェックするのが正解かと。
289 名前：デフォルトの名無しさん mailto:sage [04/10/04 19:34:44]: >>281
２ちゃんのスレは「小さなはじめの一歩」次第でどうとでも変わります。
一旦方向性をみつけると、良くも悪くもそちらへ爆走します。
どちらに向いて爆走するかは「小さなはじめの一歩」次第です。

太田氏が「方法論者(Methodologist, 社内でRUPとかの推進をしています)」であるなら
その現場で培われた成功例(例えば、知識のない人にどう啓蒙していったのか、どうや
って教育したのか、何を見せどう説明したのか等など)を書き込んでもらえると、このス
レにとって「前向きな小さなはじめの一歩」に成り得ると思うんですが・・・・・・・・

勿論、ただの要望で「もしよろしければ」という話です。
290 名前：デフォルトの名無しさん mailto:sage [04/10/04 19:56:47]: >>288
そういう情報は、「公式サイト」には書いてないからねぇ。
別に広めるつもりがないならかまわないけど。
雑誌なんかでSeasar知った人が、ブログをチェックしないといけないとは考えないだろ。
「仲間うちで使うための便利なもの作ってます。使いたければ勝手に使ってください」
というスタンスだというなら、とやかくいうつもりはないが。
291 名前：デフォルトの名無しさん [04/10/04 21:59:47]: 国産じゃデファクトスタンダードには間違っても為らないワケで。
国産唯一の利点は「ドキュメントに読みやすい日本語が期待できる」だが、
それも無いし。

結論：ｲﾗﾈ
292 名前：デフォルトの名無しさん mailto:sage [04/10/04 22:23:32]: デファクトスタンダードは難しいだろうけど、ニッチでもいいじゃん。
世の中みんながトヨタやフォードに乗ってるわけでもなければ、
OracleやDB2を使ってるわけでもないんだから。
つーか、デファクトはEJB3.0なんじゃないの？

実際の小さい仕事で使ってみて今、基本部分が出来上がったとこ。
業務ルールとそれのつなげ方を分けて管理できるライブラリ、って感じで使ってみたけど
なかなかイイよ。俺は手抜きしてついつい業務ロジックを大きく作っちゃうんだけど、
単純なクラスをDICONで連結する構造が、結構自然に簡単にできた。

慣れるまで１週間くらいはかかったけど。さすがに１時間じゃ無理ぽ。
あと、バックエンドが簡単になったらフロントの Struts の辛さ倍増。
はやくS2JSF使わせてけろ。
293 名前：デフォルトの名無しさん mailto:sage [04/10/04 22:37:47]: >>292
使ってみれば、いいことはわかるんだよ。
そのための情報が少ないのが問題だね。
ブログ騒ぎで「ここだけの話」を見てみたら、リリース情報が逐一載っていた。
唖然とした。
公式サイトのチェックはしてて、新しいもののリリースは最近ないものだと思っていた。
294 名前：デフォルトの名無しさん [04/10/05 00:05:04]: 公式サイトのwhat's newが欲しいってのはわかるなー。
295 名前：デフォルトの名無しさん mailto:sage [04/10/05 00:35:33]: MLでは逐一リリース告知されているわけだが
296 名前：デフォルトの名無しさん mailto:sage [04/10/05 01:04:23]: sourceforgeにも、リリースメモがあると思うが。
297 名前：デフォルトの名無しさん mailto:sage [04/10/05 01:09:10]: 要するに興味ないくせに文句だけは言いたいわけだ
298 名前：デフォルトの名無しさん mailto:sage [04/10/05 02:21:15]: >>293-294
ttp://sourceforge.jp/projects/seasar/news
299 名前：デフォルトの名無しさん mailto:sage [04/10/05 03:09:38]: 探さないのが問題だとも言えるし、探さないと見つけられないようなのが問題だとも言えるかも。
300 名前：デフォルトの名無しさん mailto:sage [04/10/05 07:09:43]: >>295-298
「仲間うちで使うための便利なもの作ってます。使いたければ勝手に使ってください」
というスタンスだというなら、とやかくいうつもりはないが。
301 名前：デフォルトの名無しさん mailto:sage [04/10/05 07:16:45]: とりあえず、公式サイトは吉田カバンなみ。
302 名前：デフォルトの名無しさん mailto:sage [04/10/05 09:17:27]: ていうか、Seasarに文句言ってるヤシは、Springを使ってるの？
303 名前：太田＠会社 mailto:oota_ken@hotmail.com [04/10/05 10:31:46]: 289さん>
とりあえず社内外で

patterns-wg.fuka.info.waseda.ac.jp/study/8th.html

なことや，社内でのRUP研修で紹介して興味を持ってもらっている段階です。
私は開発ではなくテストが専門なので，その分野から攻めていって「テストが効率が上がる」というと興味を持ってくれるSEが多いです。
304 名前：太田＠会社 mailto:oota_ken@hotmail.com [04/10/05 10:36:55]: あとはオブジェクト指向分析・設計の研修ですと，
やはりみなさまオブジェクト協調関係の生成をどのオブジェクトがどういったタイミングですべきかについて悩むが多いです。
そこで，Robert C. Martinのオブジェクト指向の基本原則などとからめて，DIコンテナを説明し，
もっともとっつきやすい(私の主観ですが)，Seasarを紹介するという形です。
305 名前：デフォルトの名無しさん mailto:sage [04/10/05 11:22:56]: モノ自体の仕組みとしてはとっつきやすいと思う。
SeasarのBean定義はSpringより少ない記述量でできる。
だから、わかってる人が近くにいれば、とっつきやすいと思う。
問題はわかっている人が近くにいないとき、Springの方が情報が得やすいということ。
306 名前：デフォルトの名無しさん mailto:sage [04/10/05 12:57:39]: >>305
>Springの方が情報が得やすいということ。
そうか？

Springは機能やら専門用語が多すぎて、わけわからん。
307 名前：デフォルトの名無しさん mailto:sage [04/10/05 14:08:15]: >>306
書籍に記述もあるし、網羅したリファレンスもあるし、そのモノが難しいというのは置いておいて、情報は得やすいと思う。
AOPのための記述とか、Seasarに比べるとアホみたいにめんどい。
もっと簡単な記述があるのかもしれないけど。
308 名前：デフォルトの名無しさん [04/10/05 14:58:08]: S2のJavadoc、@authorの下の行にコメント書いてある。
作者はJavadoc使ったことねぇのかな？少し笑えたぞ。
309 名前：デフォルトの名無しさん mailto:sage [04/10/05 18:10:02]: 「2chに悪意を持って書き込む奴がいる」って何をいまさらｗ
310 名前：デフォルトの名無しさん mailto:sage [04/10/05 18:59:41]: 善意がないだけで、悪意もないと思うんだけどね。
無責任なだけで。
「Seasar2はインストールするだけでシステムが不安定」とか事実ではないこと書けば、それは悪意があるんだろうけど。
311 名前：デフォルトの名無しさん mailto:sage [04/10/05 19:00:08]: >>309
ところで、どこに書いてあるの？
それ。
312 名前：デフォルトの名無しさん mailto:sage [04/10/05 19:34:49]: なんか、サイトの構築始まってるね。
左側のメニューにWhat's newが欲しい、とか、ロードマップが欲しいぞな、とかは思うが。
まあとにかく要望は出せばキリがないからほっといて、早いトコサイトインできるようにがんばって欲しいね。
せっかくWEB+DB PRESSに寄稿したり、JAVA PRESSに記事が載ったりしてんだからね。
記事みてサイトにアクセスして迷子になってあきらめる人がいるだろうから。
313 名前：デフォルトの名無しさん mailto:sage [04/10/05 19:55:27]: 307を書き込むときに、AOPのドキュメントってこんなに充実してたかなぁと思ったんだけど、やっぱり書き直されてたのね。
サイトの更新履歴も欲しいぞな。
ブログベースってことで、どうなるのかしらんけど。
まあ、関係者のブログの関連するネタを整理して、アイドルネタを省いたものになるという感じか。
314 名前：デフォルトの名無しさん [04/10/05 21:38:25]: EJB以外を使う香具師は、厨房。
315 名前：デフォルトの名無しさん mailto:sage [04/10/05 21:45:06]: >314
そんな餌（ｒｙ
316 名前：デフォルトの名無しさん mailto:sage [04/10/05 22:05:08]: というか、厨房でもなんでもいいから、動くものを早く手軽に、ってことだな。
いくら高尚で美しい設計でも、利用開始に間に合わないんじゃ仕方ない。
317 名前：デフォルトの名無しさん mailto:sage [04/10/05 22:18:29]: >316
他のコンポーネントやテーブル設計を待たずに実装とテストのフェーズに入れる＞S2Unitによるリードタイムの短縮

S2OpenAMFやS2FlexみたくWebベースでHTML以外のUIの選択肢でも連携する手立てが用意されてるのもS2の良いところかもな。
318 名前：デフォルトの名無しさん mailto:sage [04/10/05 22:24:55]: >317
他のコンポーネント→他の’関連する’コンポーネント’の実装’

>313
S2DAOのドキュメントも刷新されてますね。
319 名前：デフォルトの名無しさん mailto:sage [04/10/05 22:30:46]: 真剣に「くーす」で設計してみようと思って、ひがさんの↓
　ダイコン事態の設計手法と、その２
を読んだ。

最後の「何か合コン誘われたから行ってくるわ」が気になったので読んで見た。
関係ねーじゃねぇか＞くーす
もう帰る。ｳﾜｧｧｰﾝ
320 名前：デフォルトの名無しさん mailto:sage [04/10/05 22:37:44]: >316
御意＞いくら高尚で美しい設計
美しい設計はあくまでメンテナンス性の為の一手段に過ぎない。
そうありたいし、心掛けてるが納期に間に合って、利益を生むのが大々前提。

で、プロジェクトには新人さんも（使用するテクノロジーに）不慣れな人間も居るのが当たり前。
彼らが、この先淘汰されるかどうかは知ったことでは無いが、現実の案件をデスマらせない
には、個々のスキルに任さないのは一つの立派な考え方。

数を集めるより少数精鋭の方がコストメリットもあるとは思うけど、愚痴をたれても仕方無い。
というわけでS2が選択肢としてあって、使ってるんだが。
321 名前：デフォルトの名無しさん mailto:sage [04/10/05 22:41:10]: >319
御愁傷様（藁。くーすについては大阪のからさわぎの資料がテンプレも付いてるので興味深いな。
322 名前：316 mailto:sage [04/10/05 23:03:41]: じゃあDIは美しくない設計なのか、というと、そうじゃないんだよね。
むしろ、DIだと設計をしなくてよくなるので、美しいとか美しくないとか判定する必要もない。
各機能各層について独立したクラスを作って、ゴンゴン組み立てればいいわけだから。

どこでオブジェクト生成してどこに保持してどうやって受け渡すか、それをいかに美しい設計で実現するかなんて考える必要はないんだから。
もちろんミクロやマクロの設計はしないといけないけど、それはEJBだって助けてくれるもんじゃない。
それにミクロやマクロの設計は楽しいし。
323 名前：デフォルトの名無しさん [04/10/05 23:19:30]: without hairとか、禿げ本、禿げ会とかさー、言語の壁を隠れ蓑にして、
先人（Rod）をリスペクトしない姿勢が、鼻につくんだよ。

お前ら、Rod本人に向かって、禿げって言えんのかよ。
324 名前：デフォルトの名無しさん mailto:sage [04/10/05 23:25:07]: 他者に優しいのが、XPのペアプロに代表される少数精鋭の徒弟制度。

「スキルの無い奴」とか
「彼らが、この先淘汰されるかどうかは知ったことでは無い」とか、
結局お前、自分に優しいだけちゃうんかと。
325 名前：デフォルトの名無しさん mailto:sage [04/10/05 23:33:39]: >>324
それ作者にも言ってやれ。
326 名前：デフォルトの名無しさん mailto:sage [04/10/05 23:39:53]: >324
少数精鋭のXP、って時点でスキルの無い奴がはじき出されてるぞ。

仕事なんだから、最低水準の質を確保する仕組みってのは求めて当たり前でしょ。
そこから先、どう仕事に取り組むかは個人の問題なんだから。
327 名前：デフォルトの名無しさん mailto:sage [04/10/05 23:43:41]: >323　
コミッタでも近しい関係者でも無いよ。確かにイクナイ　＞お前ら、Rod本人に向かって、禿げって言えんのかよ。
禿しく同意だ。が、ひが氏本人が言い出した訳でもあるまい。

323本人の発言ではないと思うが、かといって逆にウンコ呼ばわりしたら同じ穴の狢でしょ？

>324
少数精鋭の徒弟制度がすくすくと育てば、ある意味で素晴らしいと思う。
で、’まず’自分に優しいのは当たり前だろ？社内のみならず協力会社を含めた遍く全ての他者が
今後、どう身を振るかまで慈悲深く’優しく’すんのかい？
328 名前：デフォルトの名無しさん mailto:sage [04/10/06 00:48:38]: >>323
Rodにハゲと言える仲になりたい。
329 名前：デフォルトの名無しさん mailto:sage [04/10/06 02:12:53]: つーか難癖つけすぎ。
粗探しばっかりでは面白くない。
330 名前：デフォルトの名無しさん [04/10/06 02:24:16]: まぁ、１のことを１０の言葉で語る人のことはさておき
（cocoon本のころは良かったのになぁ）、ちょっと本質的なネタを
振ってみたいな。

(1) S2を使うと、本当にテストがしやすくなるのか
(2) S2を使うと、本当によいものができるのか
(3) S2を使うと、本当にスキル低い人でも一定の品質を保てるのか
(4) S2を使わないと、上記のようなことはできないのか
(5) 成果物全体がS2に汚染されるけど、それはOKなのか

まぁこの際S2をDIコンテナと言い換えてもいいや。

いくつかモノを作ってみたが、(1)はまぁ同意できる。
EJB使ってるとFactory駆使しないと結合を切れないが、
その辺をフレームワークとして統括できるのは便利。
(2)～(3)は、ツールで解決するものか？という気がぬぐえない。
あと、テストパターン研究会でも話題になったが、ソースコード
トレースがし難くなるのは避けられないという問題もある。
(4)は程度の問題か。(5)はメリットとの天秤になるのかな。
インテグレーションクラス周辺だけ使う、というのが現実的か。
ところで、S2が正しくinjectionしてくれるかどうかの
テストはどう書けば？（汗）

というわけで皆の意見を聞きたい。
331 名前：デフォルトの名無しさん mailto:sage [04/10/06 03:11:04]: 似たような方向の技術ならスタンダードなものを選んで習得するのが鉄則。
となると、EJB以外の選択肢は無い訳で。
332 名前：sage [04/10/06 05:47:27]: >>330
>ソースコードトレースがし難くなるのは避けられない
これはDIの概念を読んだときからずっと気になってた。スキルの低い技術者が
出入りする大規模なプロジェクトでは影響がでかくない？

モデリングがちゃんとできる人がインターフェースの設計まで
きっちり終えてからコーディングさせないとメンテ不能なソースになりそう。
ひが氏はクラス図すらいらないみたいな事をどこかで言ってた気がするけど。

開発者もメンテナもくーすに従えば解決するのだろうか？
333 名前：332 mailto:sage [04/10/06 05:49:57]: sage間違えて恥ずかちぃ
334 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:27:38]: >>323
何だSpring派がS2叩きしてるだけか
335 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:29:10]: >>324
少数精鋭をどう育てるの？
336 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:32:15]: >>324
スキルのない奴が淘汰されるのは当然だろ？
337 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:33:15]: >>323
で、オマエはRodの言ってることどれだけ理解して実践してるの？
338 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:36:42]: で、お前等結局
１）S2が邪魔
２）ひがが嫌い
３）羽生がウザイ
のどれYO？
339 名前：219 mailto:sage [04/10/06 06:38:27]: 俺のおかげでスレも伸びたし S2 も注目されたわけだ。感謝汁！
340 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:55:09]: 羽生ウザイ
羽生はキチガイ
羽生はデブ
羽生はウンコ
羽生は氏ね！
341 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:17:30]: >323
Spring派とかいうわけでも無いんじゃね？

>331
EJBとがどこがどう似てるんだろ？スタンダードってのは
2.0なのか、それとも先の3.0のことを指してるんだろうか？
先のことを指すんであればそれこそJDOも含めて、流れが
どうなるか判らんと思うんだが

>330
(2)、(3)は今後のくーす次第かな、S2を使うからどうなるわけでもない。
(4)は疑問自体が難しいな、逆にどう思います？

(5)についてはDIコンテナが依存性を注入するので汚染？と
言われてもと思うんだけど
だからトレースやりづらくなるというのは判らなくもない
342 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:19:48]: >340
ID表示が無い板だからといって朝から釣りはやめような
343 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:25:08]: ＞＞３４２オマエ羽生だな（ｗ
344 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:25:54]: 羽生氏ね（藁
345 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:29:44]: 219頑張れ！219は正しい！219はネ申！羽生氏ね！
346 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:34:43]: >343
釣れて小躍りしてるかもしれんけど赤の他人だ、
数少ない君の人生の喜びを奪って申し訳無い。

>332
どうだろう？メンテナというかカットオーバーしてチーム
が解散、保守は引継ぎってところで発生する問題点は
まだ言及されてないんじゃないかな。

diconのまとめかたを含めて330のトレースの問題が
出てくるかもしれない。
347 名前：デフォルトの名無しさん mailto:sage [04/10/06 08:59:40]: >>330
全て、S2やSpringを使えば無条件にというわけではないというのは前提。

> (1) S2を使うと、本当にテストがしやすくなるのか

コンポーネントが独立するので異なる環境で動かしやすくなる。

> (2) S2を使うと、本当によいものができるのか

よいものの定義にもよる。
同じものであれば早くできるようになると考えれば、よいものにするための時間が多く取れるのでよいものができる確率が高いといえるかも

> (3) S2を使うと、本当にスキル低い人でも一定の品質を保てるのか

スキルが低い人が一定の品質を保てるのではなくて、スキルが低い人がいても一定の品質を保てる、だと思われ。
コンポーネントの独立度が高くなるので、スキル低い人の影響が減らせる。

> (4) S2を使わないと、上記のようなことはできないのか

DI+AOPを使わないと、初期コストがかかりがち。
ただし、その場合はプロジェクト用フレームワークをかっちり作ることになるので、DI+AOPを単純に使う場合よりも楽にできるかも。
でも、同じ努力をDI+AOPを使ってやったらもっとやりやすくなるだろう。

> (5) 成果物全体がS2に汚染されるけど、それはOKなのか

設計がDI前提のものになるだけで、個々はあまり依存しない。POJOだし。
だから、S2とSpringを切り替えることも、S2を使わなくすることも、個々の部分には影響なくできる。

と思う。
348 名前：デフォルトの名無しさん mailto:sage [04/10/06 09:02:27]: ソースコードのトレースが難しくなるって
んなもん、ＯＯＰになってから諦めてますよ

ただ、インターフェースの設計をかっちりやらないとダメなのは同意

くーすでは単なる単体テストがやりやすいとかでなくて、
設計やら仕様のテストについても言及があってしかるべしだとおもうんだが
349 名前：デフォルトの名無しさん mailto:sage [04/10/06 11:28:08]: 今更だが。

>>245 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 17:56:40
>>半角英数字の前後にスペースを入れるクセは珍しいから直したほうがいいよ

スペースが入ってるほうが見やすいだろ？
Java 標準 API ドキュメント日本語版や Eclipse 言語パック適用後みたいにな。
それとも、こいつらも珍しいから直してもらうか w
350 名前：デフォルトの名無しさん mailto:sage [04/10/06 12:21:09]: >>349
いや、キミを判別しやすくて便利だから構わんのだけど。
351 名前：デフォルトの名無しさん mailto:sage [04/10/06 16:19:56]: >んなもん、ＯＯＰになってから諦めてますよ
俺的にはOOPになってから、スキルの低い人が書いたソースは
前(構造化設計)より酷くなったけど、スキルが高い人が書いたソースは
前と比較にならないくらい読みやすくなったと思う。

クラス図を見ればどの実装がどこにあって、それぞれの責任範囲が見えてくるから。
ヘボが書いたソースは不可思議なところにメソッドが実装されていて
ソースを追うのが困難。スキルはそこそこだけどオブジェクト指向に慣れていない技術者は
画面または機能ごとにクラスを作っていて、「これじゃC言語を構造化設計で
ソースファイル分割していたのと大して変わらんなあ」というのが多い。
352 名前：デフォルトの名無しさん mailto:sage [04/10/06 17:59:54]: 要するに、クラス図があればオッケーってわけで、
なければやっぱりトレースしにくいと思う。
ソースだけで一番追いやすいのは、最後の
「スキルそこそこオブ不慣れ」のソース。
勿論良い悪いは別ですよ。

きちんとドキュメントは残しましょうって事ですかね。
353 名前：デフォルトの名無しさん mailto:sage [04/10/06 18:01:39]: ああそうか、diconファイルが上手いこと
ドキュメントになりゃいいのか。
354 名前：デフォルトの名無しさん [04/10/06 18:48:42]: そりゃそうだ。
DIベースのプログラミングの従来型からの違いはそこにあるわけだし。
355 名前：デフォルトの名無しさん mailto:sage [04/10/06 18:57:14]: >ソースだけで一番追いやすいのは、最後の
>「スキルそこそこオブ不慣れ」のソース。
それは確かにそうかも。

diconからドキュメントにするのはどうかなあ。シーケンス図をかかないと
そのインターフェースで必要十分なのかどうか判断しづらいと思う。
実装に入ってからレビューすると修正作業が多くなるので、やっぱり
あらかじめクラス図とシーケンス図を元にPLがちゃんとレビューして、
修正が終わってから実装に入った方がトータルでは楽じゃない？

まあくーすとは路線が違うのかもしれんが。
356 名前：デフォルトの名無しさん mailto:sage [04/10/06 19:14:53]: DIコンテナのBean定義ファイルは、オブジェクトの関連図になるよね。
コラボレーション図になるのかな。
357 名前：デフォルトの名無しさん mailto:sage [04/10/06 19:19:09]: >>355
そうだよなー。だから開発プロセスについて
あーだこーだ盛り上がるわけだ。

オブジェクト指向のおかげで（せいで？）
ゴリゴリ書いて動けばおしまいってのじゃ
済まなくなったと。

くーす本、楽しみです。
実業務に則して、要件定義から見積もり提示とか
そういうのまで含めてくれるととても嬉しい。
358 名前：デフォルトの名無しさん mailto:sage [04/10/06 19:30:30]: あー、見積りは嬉しいかも
359 名前：デフォルトの名無しさん mailto:sage [04/10/06 20:16:01]: くーすは、要件定義がインプットになるから、要件定義とか見積りとかは無い。
くーすでなくてもいいから、見積りは欲しい。
360 名前：デフォルトの名無しさん mailto:sage [04/10/06 20:22:12]: 結論：EJB3.0 >>> Spring >>>>> S2
361 名前：デフォルトの名無しさん mailto:sage [04/10/06 20:30:32]: EJB3.0が本当に良いならS2EJBが出るような気もするがな
362 名前：デフォルトの名無しさん mailto:sage [04/10/06 21:18:38]: SpringならGeronimo::Springがすでにあるけどね。
プロジェクトだけ。
363 名前：デフォルトの名無しさん mailto:sage 釣られ [04/10/06 21:56:25]: >360
比較できるほど三つとも使い込んでいるのか。
どこでどう差がつくのか是非教えて欲しい。
364 名前：デフォルトの名無しさん mailto:sage [04/10/06 22:04:01]: >360
リリースされてないしさ。まだまだ仕様は変わっていくので
比較は出来ないでしょ。
365 名前：デフォルトの名無しさん mailto:sage [04/10/06 22:13:01]: 是非>>360にEJBとJDOの統合による将来像というのを教えてもらいたい
366 名前：デフォルトの名無しさん mailto:sage [04/10/06 23:24:06]: ひがさんがここを見てるかもしれないんですよね？
ってことはこの板で一番要望が高いS2JSFで「こんなんほしい！」ってのを
書き込むと良いんではないでしょうか？＞ほしがってる方々
367 名前：デフォルトの名無しさん mailto:sage [04/10/06 23:35:52]: はぶ氏が作ったサイトにアクセスしてみたけど、かなり頻繁にMySQLのエラーを吐くな。

もちっと余裕があるサイトに引っ越したほうがいいような。
368 名前：デフォルトの名無しさん [04/10/06 23:48:29]: ロジックとデータの分離って、やりにくくね？
369 名前：デフォルトの名無しさん mailto:sage [04/10/06 23:54:26]: >>366
自分でひが氏のブログにコメントしろ！
ちゃんと返事来るぞ。
370 名前：デフォルトの名無しさん mailto:sage [04/10/07 00:07:47]: >>368
やりにくい部分もあるけど、やれる部分のほうが多くない？
371 名前：330 [04/10/07 00:25:56]: みんな朝からありがﾄﾝ
提案目的は、S2が使えるシチュエーションと注意事項を確認したい、ということね。

330で提示した中で、
(2)と(3)を聞いた意味は、自然なモデリングを変に崩すことになったり、制約が変な方に
働いて妙なものができてこないか
(4)は、書き方がまずかったが、DIパターンの目的である「依存関係のreasonableな分離」
を実現するためにS2は適切なのか
(5)は、importが云々という話の他に、例えば、「コンポーネントはsingleton、状態はク
ライアントが持つ」という考え方に染まったコードになり、理解者（というより共感者？）
以外は気持ち悪い思いをするよね？ということ。

個人的に気になるのは、作成するソフトウェアの複雑性を緩和するブレイクスルーがない
ように見えることなんだよな。
例えば、状態はクライアントに持たせ、コンポーネントはステートレスという思想という
か制約。データとロジックを分離させる方が有効なケースがあるのはわかる。コンポーネ
ントを作りやすくなるケースがあるのもOK（小規模な場合しか想像できないが）。
ただ、一般的には複雑性が増すわけで、適用箇所次第では、複雑性のしわ寄せがクライア
ント側にくるだろうし、コンポーネントも組みにくくなる。
さらに、346が言うように、思想を理解させなければ、こうやって組まれた構成の第三者
の理解およびメンテナンスが困難だ。

というわけで、ぶっちゃけた話、ある程度大きなアプリの適用例とメイキングオブが知り
たいわけだが。これは身をもって体験するのが一番か？
S2に限らず、J2EEのメリットが出るような規模のサンプルって、ほとんど表に出てこない
しね。抽象的か、短すぎる事例報告だけ。というわけで、もーちょっと様子見かな。
372 名前：デフォルトの名無しさん [04/10/07 00:27:23]: >>370
「構造体と関数」って感じで慣れないな。
どうしてもドメインモデルで考えてしまうYO。
ロジックをビジネスロジックとビジネスルールに分けて、
ルールの方はドメインオブジェクトに記述するのはどうだろ。

問題はS2DAOでとってきたEntityに他との関連をインジェクト
しないといけないとこだな。
373 名前：330 [04/10/07 00:27:49]: あ、ソースコードトレースがしにくいってのは、メタデータ使う
フレームワーク全般に言える事ね。オブジェクト指向レベル
どうこうというよりは、頭の中の回路を頻繁に切り替えるのが
おっくう。該当箇所探索もフレームワークのメタデータ特有の
探索方法に特化した知識や支援手段が必要になるのがウザイ。
だいたい、インピーダンスミスマッチがないレイヤーで、
別言語(?)によるコンフィギュレーション使う必然性って
あるんかいな。

テスターは再ビルド権限がないとか、SIerには再ビルド許さん
けど自由度は与えたいとか、そういう運用的理由なら、
わからんでもないが。

というわけで、DIコン使うならPico/HiveMind派（しょーもない着眼点だな、おい）。
374 名前：デフォルトの名無しさん [04/10/07 00:33:41]: ・言葉がダサイ
「ダイコン」「くーす」「から騒ぎ」ちょと恥ずかしい。

・オタくさい
から騒ぎの後、アニソンカラオケ大会。きしょい。
375 名前：デフォルトの名無しさん [04/10/07 00:48:22]: Web層　フレームワーク固有のオブジェクト
↑
DTO
↓
ビジネスロジック層　DTO or ドメインオブジェクト
↑
ドメインオブジェクト
↓
ビジネスルール層　ドメインオブジェクト
↑
ドメインオブジェクト
↓
データアクセス層

こんな感じか。
376 名前：デフォルトの名無しさん [04/10/07 00:51:41]: 戻り値にDIするインターセプタかな。
377 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:12:22]: >372
スマン、ここでのビジネスルールの粒度がイマイチ判らなかった。
揚げ足取りじゃないんだけど、ビジネスって曖昧な伝わり方もするんで、
例えばで良いんで教えて貰えますか？
PicoもHiveMindもよく知らないんだけど、どんな手順でDIするのかな？

>373
S2と関係無くメタデータと上手く付きあわないかんのもしゃあないでしょう。
ひょっとすると、今後は基本設計レベルではメタデータ定義するだけってな
思想になるかもしれんし。実装のソースコード書く人と完全分業みたいなことにも。

>374
ベタベタなほうが伝わりやすいってのもあるしさ。
あ、あとブログ読むと、アニオタ臭いのはコミュニティのごくごく一部な気もする。
ちなみに、から騒ぎ→からさわぎ、な。
378 名前：デフォルトの名無しさん [04/10/07 01:33:48]: >>377

Picoについては
www.picocontainer.org/Two+minute+tutorial
この辺みとけ。お前に与えられた時間は２分間だ（意味が逆）
クソ長いメソッドが多いが、エイリアスで短い名前も用意されてる。

>>367

ブザマだよな（苦笑）。
サービス運用規模の見積もり失敗でつか。

まーボランティアでそれなりの環境用意するのは金かかるので
大変なのはわかるが、今年は2004年です。
379 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:38:17]: >>377
思いつきなんで、はっきりとはしてないんだけど、例えば
・計算フィールドの導出
　単純な計算ですむ場合もあるし、導出にStrategyパターンを使う場合もある。

・他エンティティとの関連
　User.isMemberOf(Group)みたいなメソッドが欲しい。
　ロジック層でisMember(Group, User)ってなるとヤだなって思う。

ビジネスロジックをアクティビティ図で表すとき、それぞれのアクティビティ状態
をルールって呼ぶような感じかな。
380 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:41:39]: >>371
ソフトウェアの複雑性というのは、結局かわらないんじゃないかと思う。
単純に言えば、作るものが決まると、そのプロダクトのエントロピーの下限というのが決まるんではないかと。
そして、管理のしやすいソフトウェアというのは、エントロピーが低いソフトウェアだといえると思う。
フレームワークを使うというのは、エントロピーをフレームワークに押し付けて、コア部分のエントロピーを下げることになる。
ライブラリというのも、エントロピーをプロジェクトの外に追いやる手段だね。
あと、JavaのコードはBean定義ファイルに比べて情報量が多いから、コードを書かかずにBean定義を書くということはエントロピーを下げることにつながる。

そうやって、プロジェクトが管理する成果物のエントロピーを低い状態に保つというのが、すごくざっくり見たDI+AOPの効果ではないかな。
そういう意味では、無限の可能性をもつJavaコードを書く変わりに、数限られたXMLタグで同じことを実現する仕組みであれば、なんでもエントロピーが下げれていいんだよね。

XMLタグの表現力が上がると、それぞれのタグの情報量があがっていくから、またどこかにエントロピーを追いやる必要が出てくるわけだけど。
381 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:47:54]: それを推し進めると、浅見たん提唱のXMLによる伝票指向アーキティクチャになるのか。
382 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:48:36]: 記述の選択肢が少ない、というのが肝ね。
383 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:55:40]: S2はマンセーだけどくーすは疑問

DI（IoC）に関しては >380の言うエントロピーの軽減が目的ってことでFA。
どのコンテナがいいか。
SpringやPicoと比べると、設定の手軽さと機能の豊富さでS2が一番だと思う。
欲しい機能があったとき、Rod Johnsonにメール出すより、ひがさんのblog
にコメントする方が敷居が低いし、レスポンスも速い。
Springはクドい。

くーすは、今公開されているサンプルやトライアル程度では、実際のプロジェクト
になったときに上手くいくか判断しかねる。
本を執筆中ということだけど、付録CDに実装までのサンプルでもあればいいのだが。
今までの開発手法（ユースケース駆動とか）も、本では上手く言ってるけど、
実際大変じゃんってことで、くーすを考案中なんだし、くーすも同じ轍を踏まない
とも限らんすね。
384 名前：デフォルトの名無しさん mailto:sage [04/10/07 02:29:30]: おれはDIコンテナってのは、ファクトリを自前でがりがり書く代わりにコンテナに
お願いできる（ファクトリ機能の外出し）ってことで理解してる。
それ以外の部分（Hibernate連携とか）はあくまでオプションだと思ってる。
くーすはよくわからん。資料がたりん....
385 名前：デフォルトの名無しさん mailto:sage [04/10/07 02:53:44]: くーすの内容をみずにレス
よくある開発手法は、一般的にやろうとしてたり、実装と独立しようとしてて、使えなくなってると思われ。
くーすの場合は、業務システムをSeasar使って作るという具合に、用途を限定しているから、変に一般化しようとしなければ問題ないんじゃなかろうか。
386 名前：デフォルトの名無しさん mailto:sage [04/10/07 02:55:05]: >>385
資料っていうか、資料へのリンクがない気がする。
たぶん、探せば資料はきっとある。
387 名前：デフォルトの名無しさん mailto:sage [04/10/07 02:55:10]: くーすは特にSeasar2に限定されるものではなかったような。
388 名前：デフォルトの名無しさん mailto:sage [04/10/07 02:56:07]: 限定じゃなくて、前提だね。
389 名前：デフォルトの名無しさん mailto:sage [04/10/07 03:04:20]: ごめん、はてなの解説を「Diconを使ったときの・・・」と読み取ってしまってた。
あのへんのブログをぐるぐる回ったけど、くーす自体にはたどり着けなかった。
390 名前：デフォルトの名無しさん mailto:sage [04/10/07 03:06:06]: もうこういうの飽きた
391 名前：デフォルトの名無しさん mailto:sage [04/10/07 03:07:58]: っていうか、くーすってどこにあるの？
392 名前：371 [04/10/07 03:10:42]: >>380
大筋で同意。うまく言葉にできなかったことを、シンプルな言葉でまとめてくれてありがと。

オブジェクト指向はデータとアルゴリズムをバインドさせることで、エントロピーを低減させた
と考えることができるが（C++普及前夜に、関数ポインタを構造体に持たせたコードが増えたのが
なつかしいな）、そういう視点でのブレイクスルーがあるの？ということを
言いたかった。

自由度が小さい記述方法を使うことで局所的なエントロピーは下がると思うが、
全体的にはどうなんだろ。フレームワークと、その根底に流れる思想を理解するための
情報量の扱い、という意味で。

「くーす」という哲学を理解というか納得した者同士は、下げられるって
ことなんだろうな、たぶん。
393 名前：デフォルトの名無しさん [04/10/07 03:25:19]: >>391

弟子による「くーす」教本
marrow.strnet.com/wiki/pukiwiki.php?%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%BC%EA%CB%A1%A4%AF%A1%BC%A4%B9

ひが尊師やその弟子たちによる教えへのポインタ
www.wikiroom.com/tpircs/?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

「ダイコン時代５秒前」くらいまでは読んでみてから、
拾い読みするといいかも。少なくとも修羅場突破用
割り切り基準としては優れている。
394 名前：デフォルトの名無しさん mailto:sage [04/10/07 03:32:03]: クレクレ君ばっかだね
395 名前：デフォルトの名無しさん mailto:sage [04/10/07 03:36:29]: >>393
ありがと。
396 名前：デフォルトの名無しさん mailto:sage [04/10/07 03:37:57]: >>394
あなたみたいに頭よくないからね。
397 名前：デフォルトの名無しさん [04/10/07 03:53:58]: >>383
> 設定の手軽さと機能の豊富さでS2が一番だと思う。
設定の手軽さで一番、というのは理解できん。
XMLのvalidation考えると特に。
ある程度大きな、例えばconstractor injectionの
インスタンス数が100とか言い出すと、コストが逆転する
かもしれんけど（まぁそこまでいくとXMLも専用エディタ
使わんと苦しいな）。
フィーリングとしてどれくらい？＞リーズナブルな規模

機能の豊富さはXMLの表現力と等価なわけで、情報量が（略）。

相手が日本人だと楽、というのは同意。自分も含めて
技術者として情けないがな……。一時期、Xalanコミュニティ
とかに顔つっこんでみたことがあるけど、やっぱりスケール
の違いを感じた。ロシア人の英語はよめねー。

>>384
そうね。個人的にもそこがコアだと思う。
AOPはそれを効率よく実現するための手段という考え。
そもそも「FactoryやAFactoryはDIコンテナで代用
できます！」ってのは、DIがFactoryの一流派だけ
なんじゃないかと小一時間（略
398 名前：デフォルトの名無しさん mailto:sage [04/10/07 10:26:57]: >>367

鯖提供者募集中だそうです。
399 名前：デフォルトの名無しさん mailto:sage [04/10/07 11:07:16]: しかし、こういうリフレクション全開のしくみが定着すると、いままで語られてた
「型安全性」だとか「コンパイルによる事前検証」のメリットってどうよ？と思わないでもない。
400 名前：デフォルトの名無しさん mailto:sage [04/10/07 14:10:56]: >>399
大いにそう思う。
いままでだと、型の安全性ってのは基本的にコンパイラが
あるていどの保証(とはいってもぴんきりだが)を
してくれていたわけだが、そういった部分に頼れないと
いうことだからね。
401 名前：デフォルトの名無しさん mailto:sage [04/10/07 16:46:22]: 強い型付けはJavaのウリでもあるけども、オブジェクト指向的な利点を
徹底利用しにくいところもあったね。たとえばListnerを使ったコールバック的な
委譲モデルでも、おれはListnerインターフェイスをimplementsするんじゃなくて、
モデル側にMethodオブジェクトを渡してやるほうがなんぼかましじゃないかと
思ったりもするし。
たとえばThreadにRunnableオブジェクトを渡すんじゃなくて、実行して
ほしいMethodを渡して、Thread側ではinvoke()するとかのほうがもっとフレキシ
ブルなんじゃないかと。Runnableをimplementsする必要すらなくなるし。
こういう、型なんて関係ない、メソッドがあればいい、という使い方は本来、
オブジェクト指向ならではだったわけで。

DIコンテナの場合、利用側ではインターフェイスをもとにしたプログラミングを
行なうわけで、型安全性も十分保証できてると思うし。
402 名前：デフォルトの名無しさん mailto:sage [04/10/07 17:14:14]: キャストごりごりのコードになるよね？
403 名前：デフォルトの名無しさん mailto:sage [04/10/07 17:28:17]: >>401
C#のデリゲート、MSがJavaの仕様に入れようと提案したら
Sunに断られたそうで。
404 名前：デフォルトの名無しさん mailto:sage [04/10/07 17:29:09]: そうだな、DIコンテナ使うとキャストは増える。Object型返すしなあ。
たしかにそこでの型安全性は低くなってると思う。Cast例外って
実行時例外だったよなあ。
405 名前：デフォルトの名無しさん mailto:sage [04/10/07 17:39:34]: キャストは増えない。setter使えば勝手に入れてくれるから
406 名前：デフォルトの名無しさん mailto:sage [04/10/07 18:37:15]: 最初の入り口さえどうにかすれば、あとは大丈夫という感じだね。
そういえば。
オブジェクトの遅延生成ができるともっといいね。
遅延というか、オンデマンド。
getXxx使ったときに生成されるような。
じゃないとイモヅル式にオブジェクトが生成されてしまう。

できるんだっけ？
407 名前：デフォルトの名無しさん mailto:sage [04/10/07 19:26:43]: >>405
いやコンテナ内のオブジェクトはいいんだよ。増えるところは

S2の例：
Hello hello = (Hello) container.getComponent(Hello.class);

この部分ね。まあ対した問題じゃないんだけどね。文法上
cast失敗を気にする必要もないだろうし。
408 名前：デフォルトの名無しさん mailto:sage [04/10/07 19:58:36]: 使うとわかるけどcontainerの外でcontainerを使う方が珍しいと思う
409 名前：sage [04/10/07 20:27:27]: まー依存性注入するところでcontainer使うんだから、
奇麗に設計できている場合はそうね。
410 名前：デフォルトの名無しさん mailto:sage [04/10/07 20:43:38]: インスタンスがいもづる式に生成されまくるという問題ってないの？
411 名前：デフォルトの名無しさん mailto:sage [04/10/07 20:57:04]: インスタンスはcontainerが保持しているから問題なし
412 名前：デフォルトの名無しさん mailto:sage [04/10/07 21:15:04]: そのメモリはどこから出てくるの？
413 名前：デフォルトの名無しさん [04/10/07 21:24:48]: >>380はエントロピーって言葉に何か間違ったイメージを持ってるな
414 名前：デフォルトの名無しさん mailto:sage [04/10/07 21:34:59]: >410
基本はSingletonだ
415 名前：デフォルトの名無しさん mailto:sage [04/10/07 21:36:14]: ソフトウェアにおけるエントロピーの定義を教えてくれませんか？
416 名前：デフォルトの名無しさん mailto:sage [04/10/07 22:09:49]: >>414
そうすると、ソフトウェア中で必要なオブジェクトがすべて生成されてしまうことにならないかな。
417 名前：デフォルトの名無しさん mailto:sage [04/10/07 22:13:33]: >>415
これぐらいは自力で調べる癖をつけようね。
ja.wikipedia.org/wiki/%E3%82%A8%E3%83%B3%E3%83%88%E3%83%AD%E3%83%94%E3%83%BC
これの「情報理論におけるエントロピー」のところにある。
> ある確率分布 p(x) をもつ確率変数 X が与えられたとき、
>
> H(X) = -Σ_{x∈X}{p(x)log(p(x))}
>
>この量 H を確率変数 X のエントロピーという。
418 名前：デフォルトの名無しさん mailto:sage [04/10/07 22:20:41]: >>413
その言葉のもつ本来の意味を知らず、また、知ろうともせず、
単に語感やニュアンスだけでカッコいい言葉を使ってみる、
というのはどこに行ってもありがちだけどね。
>>380の言わんとしていることは分かったけど。
419 名前：デフォルトの名無しさん mailto:sage [04/10/07 22:23:27]: >>415
ソフトウェアにおけるもなにも、エントロピーは情報量の平均だよ。
整理されてなく、どこになにがあるかわからないソフトウェアはエントロピーが高い。
Javaのコードは選択肢が多いから、一行の情報量が多い。
対して、SeasarやSpringなどのBean定義ファイルは選択肢が少ないので情報量が少ない。
また、規模の大きいソフトウェアも、行ごとの情報量が大きくなる。

系が閉じているときのエントロピーの総和は一定なので、どこかのエントロピーを下げようと思うとどこかにエントロピーを押し付ける必要がある。
整理してどこになにがあるか推測しやすい状態で、選択肢の少ないコーディング技術を使って、コード量を少なくすると、エントロピーが低くなる。
作成するソフトウェアのエントロピーを下げようと思えば、ライブラリやフレームワークを使うことのほかに、開発管理がある。
管理された成果物のエントロピーは低いけど、管理作業自体のエントロピーが高いから。
420 名前：415 mailto:sage [04/10/07 22:35:34]: >>417,419
ありがとうございました。勉強になりました。
421 名前：デフォルトの名無しさん [04/10/07 22:58:07]: くーすを実案件に適用した例ってあるのかな？
422 名前：デフォルトの名無しさん mailto:sage [04/10/07 23:05:47]: いまオフショア開発でやってるんじゃなかったっけ？
423 名前：デフォルトの名無しさん mailto:sage [04/10/07 23:08:14]: >>420
-log(p(x))っていうのが情報量ね。確率の対数。で、エントロピーは情報量の平均(期待値)
424 名前：デフォルトの名無しさん mailto:sage [04/10/07 23:17:48]: ×確率の対数
○確率の逆数の対数

文法のルールが多いほどコードのエントロピーは低くなる。
だから、Javaのコードは型の緩い言語よりエントロピーが低くなるんだね。
そのかわり、文法を勉強するためのエントロピーが高くなる。
425 名前：デフォルトの名無しさん mailto:sage [04/10/08 01:13:25]: >>416
すべて生成したとしてもデータを持たないオブジェクトという前提ならそれほど問題ないのでは？
426 名前：デフォルトの名無しさん mailto:sage [04/10/08 01:15:39]: >416
ソフトウェア中で必要なすべてじゃなくて、DIContainerに登録されているものすべて。
prototypeとouterを除く。

なんでもかんでもDIContainerに登録するわけじゃないよ。
多分416が思ってるほど多くはない。
427 名前：デフォルトの名無しさん mailto:sage [04/10/08 01:23:41]: JFrameとかを登録する方針にしたら、えらいことなりそうだけど。
428 名前：デフォルトの名無しさん mailto:sage [04/10/08 01:35:41]: VBとかDelphiで起動時に全フォームクリエイトしておいて
使うときにはShow()するような感じ？

Delphiでちゃんとしたアプリ作るときはちゃんと生成・消滅を管理するけど(VBはシラネ)、
429 名前：デフォルトの名無しさん mailto:sage [04/10/08 01:45:53]: そう、そんな感じ。
JFrameはシングルトンにしなければいいのかな。
430 名前：デフォルトの名無しさん [04/10/08 03:27:40]: ＞ソフトウェアにおけるもなにも、エントロピーは情報量の平均だよ。

…ヲイヲイ…。
431 名前：デフォルトの名無しさん [04/10/08 03:43:00]: JFrameをDIContainerに登録するなら、prototypeになるはずだから
問題なしだ。VB、Delphiは良く知らんが、一つだけインスタンスを
生成しておいて、必要な時はコピーを生成してShow()するようになる。

これくらい分からんような奴らが、「ドキュメントすくねえ」とか
「全然優しくねえ」とかほざいてるのであれば、ひが氏は気に留める
必要ない。ドキュメント整備した所で使えねーよ。
S2Daoの機能強化やS2JSFの方に注力して欲しい。
432 名前：デフォルトの名無しさん [04/10/08 05:12:15]: 前に羽生さんに粘着してた香具師がいたような。。。
ここにもいたりしてw
433 名前：デフォルトの名無しさん mailto:sage [04/10/08 09:14:31]: >>430
じゃエントロピーってなに？
434 名前：デフォルトの名無しさん mailto:sage [04/10/08 09:45:49]: >>417の定義のままだと思うのだが。
435 名前：デフォルトの名無しさん mailto:sage [04/10/08 09:51:35]: >>433
俺≠430だけど、こんな感じじゃない。

持ちうるデータのバリエーションの許容量⇒情報量
それの系全体(平均)⇒エントロピー

あるいは、バリエーションの許容量ではなく
絶対量そのものを指す人も多いかも。
どちらにせよ、Wikipediaのと違いはないと思う。
436 名前：433 mailto:sage [04/10/08 10:00:18]: >>435
実は、情報量と書いてる部分も、エントロピーと書くべきだった気がする。
情報量っていうのは、たとえばJavaコードを1行取り出したときに
S2Container container = S2ContainerFactory.create(PATH);
だったときにどれだけ意外性があるか、という、それぞれの事象に対する量だからね。
437 名前：デフォルトの名無しさん mailto:sage [04/10/08 10:06:07]: >>431
こういう、足りない点を指摘するやつをバカにする方が、スレを荒らしてるわけだが。
こうやって評判落とすようなマネするのって、ヒガさんに実は恨みがあるから？
438 名前：デフォルトの名無しさん mailto:sage [04/10/08 10:55:14]: >>432
そりゃいるだろ。2chだからな。
439 名前：デフォルトの名無しさん mailto:sage [04/10/08 10:57:34]: >>437
恨みはないかもしれないが
妬みややっかみを持っている
ヤシはいるんだろうな。
440 名前：デフォルトの名無しさん mailto:sage [04/10/08 10:58:46]: >>438
羽生さんもいるくらいだからな。
441 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:00:56]: >>439
で、ひがさんを擁護するフリをして、Seasar2は敷居が高い、とか、欠点に対する指摘を受け付けない、とかそういう逆宣伝をしてるわけか。
442 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:03:29]: >>440
羽生さんがいるところには常に粘着するわけか。
大変だな。羽生さんも追っかけもｗ
443 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:04:03]: 恨みを買ってもしょうがないようなところあるからな。
人の話を遮って自分だけ延々と喋るし。
たいていは人の話に耳を貸さないくせにそれは相手によるし。
嫌いなやつは多いだろう。
444 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:07:09]: >>443
まあそういう話はスレ違いってことで。
呼び出しくらうよ。
445 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:08:04]: >>443
何だオマエ知り合いなのか。
本人に直接言ってやれよｗ
446 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:12:59]: 直接言えないから粘着してるんだよｗ
447 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:15:20]: それにしても、よく観察してるね。
448 名前：デフォルトの名無しさん [04/10/08 11:22:09]: DIの利点って、分からん奴らにはメソッドの仕様だけ渡して、
その部分だけ他に影響を与えずに作らせることができるという
ことだと思います。
Rodの本なんかを読んだり、ソース調べたり、自分で試したり
できる人とできない人で、Seasarに関わる人は分化されるのです。
S２を作る人、使う人、使われる人の３種類になるのでしょう。
それぞれのスキルにあった役割を与える。これも優しさです。

使われる人は、他に問題を波及させずにとりあえず、与えられた
メソッドの実装を行えばよくなります。
使う人は、実装を外注しやすくなり、Springと比べてもテストや
設定が格段に楽になります。

その点の説明が公式サイトにないので（日記にはあるが）使われる人が
勘違いして、ちょっと調べれば分かることをここでゴチャゴチャ騒いで
いることでしょう。

ドキュメントの整備は大歓迎です。ただ他の方に注力して欲しい。
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