04/10/06 09:02:27
ソースコードのトレースが難しくなるって
んなもん、ＯＯＰになってから諦めてますよ
ただ、インターフェースの設計をかっちりやらないとダメなのは同意
くーすでは単なる単体テストがやりやすいとかでなくて、
設計やら仕様のテストについても言及があってしかるべしだとおもうんだが
349:デフォルトの名無しさん
04/10/06 11:28:08
今更だが。
>>245 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 17:56:40
>>半角英数字の前後にスペースを入れるクセは珍しいから直したほうがいいよ
スペースが入ってるほうが見やすいだろ？
Java 標準 API ドキュメント日本語版や Eclipse 言語パック適用後みたいにな。
それとも、こいつらも珍しいから直してもらうか w
350:デフォルトの名無しさん
04/10/06 12:21:09
>>349
いや、キミを判別しやすくて便利だから構わんのだけど。
351:デフォルトの名無しさん
04/10/06 16:19:56
>んなもん、ＯＯＰになってから諦めてますよ
俺的にはOOPになってから、スキルの低い人が書いたソースは
前(構造化設計)より酷くなったけど、スキルが高い人が書いたソースは
前と比較にならないくらい読みやすくなったと思う。
クラス図を見ればどの実装がどこにあって、それぞれの責任範囲が見えてくるから。
ヘボが書いたソースは不可思議なところにメソッドが実装されていて
ソースを追うのが困難。スキルはそこそこだけどオブジェクト指向に慣れていない技術者は
画面または機能ごとにクラスを作っていて、「これじゃC言語を構造化設計で
ソースファイル分割していたのと大して変わらんなあ」というのが多い。
352:デフォルトの名無しさん
04/10/06 17:59:54
要するに、クラス図があればオッケーってわけで、
なければやっぱりトレースしにくいと思う。
ソースだけで一番追いやすいのは、最後の
「スキルそこそこオブ不慣れ」のソース。
勿論良い悪いは別ですよ。
きちんとドキュメントは残しましょうって事ですかね。
353:デフォルトの名無しさん
04/10/06 18:01:39
ああそうか、diconファイルが上手いこと
ドキュメントになりゃいいのか。
354:デフォルトの名無しさん
04/10/06 18:48:42
そりゃそうだ。
DIベースのプログラミングの従来型からの違いはそこにあるわけだし。
355:デフォルトの名無しさん
04/10/06 18:57:14
>ソースだけで一番追いやすいのは、最後の
>「スキルそこそこオブ不慣れ」のソース。
それは確かにそうかも。
diconからドキュメントにするのはどうかなあ。シーケンス図をかかないと
そのインターフェースで必要十分なのかどうか判断しづらいと思う。
実装に入ってからレビューすると修正作業が多くなるので、やっぱり
あらかじめクラス図とシーケンス図を元にPLがちゃんとレビューして、
修正が終わってから実装に入った方がトータルでは楽じゃない？
まあくーすとは路線が違うのかもしれんが。
356:デフォルトの名無しさん
04/10/06 19:14:53
DIコンテナのBean定義ファイルは、オブジェクトの関連図になるよね。
コラボレーション図になるのかな。
357:デフォルトの名無しさん
04/10/06 19:19:09
>>355
そうだよなー。だから開発プロセスについて
あーだこーだ盛り上がるわけだ。
オブジェクト指向のおかげで（せいで？）
ゴリゴリ書いて動けばおしまいってのじゃ
済まなくなったと。
くーす本、楽しみです。
実業務に則して、要件定義から見積もり提示とか
そういうのまで含めてくれるととても嬉しい。
358:デフォルトの名無しさん
04/10/06 19:30:30
あー、見積りは嬉しいかも
359:デフォルトの名無しさん
04/10/06 20:16:01
くーすは、要件定義がインプットになるから、要件定義とか見積りとかは無い。
くーすでなくてもいいから、見積りは欲しい。
360:デフォルトの名無しさん
04/10/06 20:22:12
結論：EJB3.0 >>> Spring >>>>> S2
361:デフォルトの名無しさん
04/10/06 20:30:32
EJB3.0が本当に良いならS2EJBが出るような気もするがな
362:デフォルトの名無しさん
04/10/06 21:18:38
SpringならGeronimo::Springがすでにあるけどね。
プロジェクトだけ。
363:デフォルトの名無しさん
04/10/06 21:56:25
>360
比較できるほど三つとも使い込んでいるのか。
どこでどう差がつくのか是非教えて欲しい。
364:デフォルトの名無しさん
04/10/06 22:04:01
>360
リリースされてないしさ。まだまだ仕様は変わっていくので
比較は出来ないでしょ。
365:デフォルトの名無しさん
04/10/06 22:13:01
是非>>360にEJBとJDOの統合による将来像というのを教えてもらいたい
366:デフォルトの名無しさん
04/10/06 23:24:06
ひがさんがここを見てるかもしれないんですよね？
ってことはこの板で一番要望が高いS2JSFで「こんなんほしい！」ってのを
書き込むと良いんではないでしょうか？＞ほしがってる方々
367:デフォルトの名無しさん
04/10/06 23:35:52
はぶ氏が作ったサイトにアクセスしてみたけど、かなり頻繁にMySQLのエラーを吐くな。
もちっと余裕があるサイトに引っ越したほうがいいような。
368:デフォルトの名無しさん
04/10/06 23:48:29
ロジックとデータの分離って、やりにくくね？
369:デフォルトの名無しさん
04/10/06 23:54:26
>>366
自分でひが氏のブログにコメントしろ！
ちゃんと返事来るぞ。
370:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/07 01:12:22
>372
スマン、ここでのビジネスルールの粒度がイマイチ判らなかった。
揚げ足取りじゃないんだけど、ビジネスって曖昧な伝わり方もするんで、
例えばで良いんで教えて貰えますか？
PicoもHiveMindもよく知らないんだけど、どんな手順でDIするのかな？
>373
S2と関係無くメタデータと上手く付きあわないかんのもしゃあないでしょう。
ひょっとすると、今後は基本設計レベルではメタデータ定義するだけってな
思想になるかもしれんし。実装のソースコード書く人と完全分業みたいなことにも。
>374
ベタベタなほうが伝わりやすいってのもあるしさ。
あ、あとブログ読むと、アニオタ臭いのはコミュニティのごくごく一部な気もする。
ちなみに、から騒ぎ→からさわぎ、な。
378:デフォルトの名無しさん
04/10/07 01:33:48
>>377
Picoについては
URLﾘﾝｸ(www.picocontainer.org)
この辺みとけ。お前に与えられた時間は２分間だ（意味が逆）
クソ長いメソッドが多いが、エイリアスで短い名前も用意されてる。
>>367
ブザマだよな（苦笑）。
サービス運用規模の見積もり失敗でつか。
まーボランティアでそれなりの環境用意するのは金かかるので
大変なのはわかるが、今年は2004年です。
379:デフォルトの名無しさん
04/10/07 01:38:17
>>377
思いつきなんで、はっきりとはしてないんだけど、例えば
・計算フィールドの導出
単純な計算ですむ場合もあるし、導出にStrategyパターンを使う場合もある。
・他エンティティとの関連
User.isMemberOf(Group)みたいなメソッドが欲しい。
ロジック層でisMember(Group, User)ってなるとヤだなって思う。
ビジネスロジックをアクティビティ図で表すとき、それぞれのアクティビティ状態
をルールって呼ぶような感じかな。
380:デフォルトの名無しさん
04/10/07 01:41:39
>>371
ソフトウェアの複雑性というのは、結局かわらないんじゃないかと思う。
単純に言えば、作るものが決まると、そのプロダクトのエントロピーの下限というのが決まるんではないかと。
そして、管理のしやすいソフトウェアというのは、エントロピーが低いソフトウェアだといえると思う。
フレームワークを使うというのは、エントロピーをフレームワークに押し付けて、コア部分のエントロピーを下げることになる。
ライブラリというのも、エントロピーをプロジェクトの外に追いやる手段だね。
あと、JavaのコードはBean定義ファイルに比べて情報量が多いから、コードを書かかずにBean定義を書くということはエントロピーを下げることにつながる。
そうやって、プロジェクトが管理する成果物のエントロピーを低い状態に保つというのが、すごくざっくり見たDI+AOPの効果ではないかな。
そういう意味では、無限の可能性をもつJavaコードを書く変わりに、数限られたXMLタグで同じことを実現する仕組みであれば、なんでもエントロピーが下げれていいんだよね。
XMLタグの表現力が上がると、それぞれのタグの情報量があがっていくから、またどこかにエントロピーを追いやる必要が出てくるわけだけど。
381:デフォルトの名無しさん
04/10/07 01:47:54
それを推し進めると、浅見たん提唱のXMLによる伝票指向アーキティクチャになるのか。
382:デフォルトの名無しさん
04/10/07 01:48:36
記述の選択肢が少ない、というのが肝ね。
383:デフォルトの名無しさん
04/10/07 01:55:40
S2はマンセーだけどくーすは疑問
DI（IoC）に関しては >380の言うエントロピーの軽減が目的ってことでFA。
どのコンテナがいいか。
SpringやPicoと比べると、設定の手軽さと機能の豊富さでS2が一番だと思う。
欲しい機能があったとき、Rod Johnsonにメール出すより、ひがさんのblog
にコメントする方が敷居が低いし、レスポンスも速い。
Springはクドい。
くーすは、今公開されているサンプルやトライアル程度では、実際のプロジェクト
になったときに上手くいくか判断しかねる。
本を執筆中ということだけど、付録CDに実装までのサンプルでもあればいいのだが。
今までの開発手法（ユースケース駆動とか）も、本では上手く言ってるけど、
実際大変じゃんってことで、くーすを考案中なんだし、くーすも同じ轍を踏まない
とも限らんすね。
384:デフォルトの名無しさん
04/10/07 02:29:30
おれはDIコンテナってのは、ファクトリを自前でがりがり書く代わりにコンテナに
お願いできる（ファクトリ機能の外出し）ってことで理解してる。
それ以外の部分（Hibernate連携とか）はあくまでオプションだと思ってる。
くーすはよくわからん。資料がたりん....
385:デフォルトの名無しさん
04/10/07 02:53:44
くーすの内容をみずにレス
よくある開発手法は、一般的にやろうとしてたり、実装と独立しようとしてて、使えなくなってると思われ。
くーすの場合は、業務システムをSeasar使って作るという具合に、用途を限定しているから、変に一般化しようとしなければ問題ないんじゃなかろうか。
386:デフォルトの名無しさん
04/10/07 02:55:05
>>385
資料っていうか、資料へのリンクがない気がする。
たぶん、探せば資料はきっとある。
387:デフォルトの名無しさん
04/10/07 02:55:10
くーすは特にSeasar2に限定されるものではなかったような。
388:デフォルトの名無しさん
04/10/07 02:56:07
限定じゃなくて、前提だね。
389:デフォルトの名無しさん
04/10/07 03:04:20
ごめん、はてなの解説を「Diconを使ったときの・・・」と読み取ってしまってた。
あのへんのブログをぐるぐる回ったけど、くーす自体にはたどり着けなかった。
390:デフォルトの名無しさん
04/10/07 03:06:06
もうこういうの飽きた
391:デフォルトの名無しさん
04/10/07 03:07:58
っていうか、くーすってどこにあるの？
392:371
04/10/07 03:10:42
>>380
大筋で同意。うまく言葉にできなかったことを、シンプルな言葉でまとめてくれてありがと。
オブジェクト指向はデータとアルゴリズムをバインドさせることで、エントロピーを低減させた
と考えることができるが（C++普及前夜に、関数ポインタを構造体に持たせたコードが増えたのが
なつかしいな）、そういう視点でのブレイクスルーがあるの？ということを
言いたかった。
自由度が小さい記述方法を使うことで局所的なエントロピーは下がると思うが、
全体的にはどうなんだろ。フレームワークと、その根底に流れる思想を理解するための
情報量の扱い、という意味で。
「くーす」という哲学を理解というか納得した者同士は、下げられるって
ことなんだろうな、たぶん。
393:デフォルトの名無しさん
04/10/07 03:25:19
>>391
弟子による「くーす」教本
URLﾘﾝｸ(marrow.strnet.com)
ひが尊師やその弟子たちによる教えへのポインタ
URLﾘﾝｸ(www.wikiroom.com)
「ダイコン時代５秒前」くらいまでは読んでみてから、
拾い読みするといいかも。少なくとも修羅場突破用
割り切り基準としては優れている。
394:デフォルトの名無しさん
04/10/07 03:32:03
クレクレ君ばっかだね
395:デフォルトの名無しさん
04/10/07 03:36:29
>>393
ありがと。
396:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/07 10:26:57
>>367
鯖提供者募集中だそうです。
399:デフォルトの名無しさん
04/10/07 11:07:16
しかし、こういうリフレクション全開のしくみが定着すると、いままで語られてた
「型安全性」だとか「コンパイルによる事前検証」のメリットってどうよ？と思わないでもない。
400:デフォルトの名無しさん
04/10/07 14:10:56
>>399
大いにそう思う。
いままでだと、型の安全性ってのは基本的にコンパイラが
あるていどの保証(とはいってもぴんきりだが)を
してくれていたわけだが、そういった部分に頼れないと
いうことだからね。
401:デフォルトの名無しさん
04/10/07 16:46:22
強い型付けはJavaのウリでもあるけども、オブジェクト指向的な利点を
徹底利用しにくいところもあったね。たとえばListnerを使ったコールバック的な
委譲モデルでも、おれはListnerインターフェイスをimplementsするんじゃなくて、
モデル側にMethodオブジェクトを渡してやるほうがなんぼかましじゃないかと
思ったりもするし。
たとえばThreadにRunnableオブジェクトを渡すんじゃなくて、実行して
ほしいMethodを渡して、Thread側ではinvoke()するとかのほうがもっとフレキシ
ブルなんじゃないかと。Runnableをimplementsする必要すらなくなるし。
こういう、型なんて関係ない、メソッドがあればいい、という使い方は本来、
オブジェクト指向ならではだったわけで。
DIコンテナの場合、利用側ではインターフェイスをもとにしたプログラミングを
行なうわけで、型安全性も十分保証できてると思うし。
402:デフォルトの名無しさん
04/10/07 17:14:14
キャストごりごりのコードになるよね？
403:デフォルトの名無しさん
04/10/07 17:28:17
>>401
C#のデリゲート、MSがJavaの仕様に入れようと提案したら
Sunに断られたそうで。
404:デフォルトの名無しさん
04/10/07 17:29:09
そうだな、DIコンテナ使うとキャストは増える。Object型返すしなあ。
たしかにそこでの型安全性は低くなってると思う。Cast例外って
実行時例外だったよなあ。
405:デフォルトの名無しさん
04/10/07 17:39:34
キャストは増えない。setter使えば勝手に入れてくれるから
406:デフォルトの名無しさん
04/10/07 18:37:15
最初の入り口さえどうにかすれば、あとは大丈夫という感じだね。
そういえば。
オブジェクトの遅延生成ができるともっといいね。
遅延というか、オンデマンド。
getXxx使ったときに生成されるような。
じゃないとイモヅル式にオブジェクトが生成されてしまう。
できるんだっけ？
407:デフォルトの名無しさん
04/10/07 19:26:43
>>405
いやコンテナ内のオブジェクトはいいんだよ。増えるところは
S2の例：
Hello hello = (Hello) container.getComponent(Hello.class);
この部分ね。まあ対した問題じゃないんだけどね。文法上
cast失敗を気にする必要もないだろうし。
408:デフォルトの名無しさん
04/10/07 19:58:36
使うとわかるけどcontainerの外でcontainerを使う方が珍しいと思う
409:sage
04/10/07 20:27:27
まー依存性注入するところでcontainer使うんだから、
奇麗に設計できている場合はそうね。
410:デフォルトの名無しさん
04/10/07 20:43:38
インスタンスがいもづる式に生成されまくるという問題ってないの？
411:デフォルトの名無しさん
04/10/07 20:57:04
インスタンスはcontainerが保持しているから問題なし
412:デフォルトの名無しさん
04/10/07 21:15:04
そのメモリはどこから出てくるの？
413:デフォルトの名無しさん
04/10/07 21:24:48
>>380はエントロピーって言葉に何か間違ったイメージを持ってるな
414:デフォルトの名無しさん
04/10/07 21:34:59
>410
基本はSingletonだ
415:デフォルトの名無しさん
04/10/07 21:36:14
ソフトウェアにおけるエントロピーの定義を教えてくれませんか？
416:デフォルトの名無しさん
04/10/07 22:09:49
>>414
そうすると、ソフトウェア中で必要なオブジェクトがすべて生成されてしまうことにならないかな。
417:デフォルトの名無しさん
04/10/07 22:13:33
>>415
これぐらいは自力で調べる癖をつけようね。
URLﾘﾝｸ(ja.wikipedia.org)
これの「情報理論におけるエントロピー」のところにある。
> ある確率分布 p(x) をもつ確率変数 X が与えられたとき、
>
> H(X) = -Σ_{x∈X}{p(x)log(p(x))}
>
>この量 H を 確率変数 X のエントロピー という。
418:デフォルトの名無しさん
04/10/07 22:20:41
>>413
その言葉のもつ本来の意味を知らず、また、知ろうともせず、
単に語感やニュアンスだけでカッコいい言葉を使ってみる、
というのはどこに行ってもありがちだけどね。
>>380の言わんとしていることは分かったけど。
419:デフォルトの名無しさん
04/10/07 22:23:27
>>415
ソフトウェアにおけるもなにも、エントロピーは情報量の平均だよ。
整理されてなく、どこになにがあるかわからないソフトウェアはエントロピーが高い。
Javaのコードは選択肢が多いから、一行の情報量が多い。
対して、SeasarやSpringなどのBean定義ファイルは選択肢が少ないので情報量が少ない。
また、規模の大きいソフトウェアも、行ごとの情報量が大きくなる。
系が閉じているときのエントロピーの総和は一定なので、どこかのエントロピーを下げようと思うとどこかにエントロピーを押し付ける必要がある。
整理してどこになにがあるか推測しやすい状態で、選択肢の少ないコーディング技術を使って、コード量を少なくすると、エントロピーが低くなる。
作成するソフトウェアのエントロピーを下げようと思えば、ライブラリやフレームワークを使うことのほかに、開発管理がある。
管理された成果物のエントロピーは低いけど、管理作業自体のエントロピーが高いから。
420:415
04/10/07 22:35:34
>>417,419
ありがとうございました。勉強になりました。
421:デフォルトの名無しさん
04/10/07 22:58:07
くーすを実案件に適用した例ってあるのかな？
422:デフォルトの名無しさん
04/10/07 23:05:47
いまオフショア開発でやってるんじゃなかったっけ？
423:デフォルトの名無しさん
04/10/07 23:08:14
>>420
-log(p(x))っていうのが情報量ね。確率の対数。で、エントロピーは情報量の平均(期待値)
424:デフォルトの名無しさん
04/10/07 23:17:48
×確率の対数
○確率の逆数の対数
文法のルールが多いほどコードのエントロピーは低くなる。
だから、Javaのコードは型の緩い言語よりエントロピーが低くなるんだね。
そのかわり、文法を勉強するためのエントロピーが高くなる。
425:デフォルトの名無しさん
04/10/08 01:13:25
>>416
すべて生成したとしてもデータを持たないオブジェクトという前提ならそれほど問題ないのでは？
426:デフォルトの名無しさん
04/10/08 01:15:39
>416
ソフトウェア中で必要なすべてじゃなくて、DIContainerに登録されているものすべて。
prototypeとouterを除く。
なんでもかんでもDIContainerに登録するわけじゃないよ。
多分416が思ってるほど多くはない。
427:デフォルトの名無しさん
04/10/08 01:23:41
JFrameとかを登録する方針にしたら、えらいことなりそうだけど。
428:デフォルトの名無しさん
04/10/08 01:35:41
VBとかDelphiで起動時に全フォームクリエイトしておいて
使うときにはShow()するような感じ？
Delphiでちゃんとしたアプリ作るときはちゃんと生成・消滅を管理するけど(VBはシラネ)、
429:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/08 09:14:31
>>430
じゃエントロピーってなに？
434:デフォルトの名無しさん
04/10/08 09:45:49
>>417の定義のままだと思うのだが。
435:デフォルトの名無しさん
04/10/08 09:51:35
>>433
俺≠430だけど、こんな感じじゃない。
持ちうるデータのバリエーションの許容量⇒情報量
それの系全体(平均)⇒エントロピー
あるいは、バリエーションの許容量ではなく
絶対量そのものを指す人も多いかも。
どちらにせよ、Wikipediaのと違いはないと思う。
436:433
04/10/08 10:00:18
>>435
実は、情報量と書いてる部分も、エントロピーと書くべきだった気がする。
情報量っていうのは、たとえばJavaコードを1行取り出したときに
S2Container container = S2ContainerFactory.create(PATH);
だったときにどれだけ意外性があるか、という、それぞれの事象に対する量だからね。
437:デフォルトの名無しさん
04/10/08 10:06:07
>>431
こういう、足りない点を指摘するやつをバカにする方が、スレを荒らしてるわけだが。
こうやって評判落とすようなマネするのって、ヒガさんに実は恨みがあるから？
438:デフォルトの名無しさん
04/10/08 10:55:14
>>432
そりゃいるだろ。2chだからな。
439:デフォルトの名無しさん
04/10/08 10:57:34
>>437
恨みはないかもしれないが
妬みややっかみを持っている
ヤシはいるんだろうな。
440:デフォルトの名無しさん
04/10/08 10:58:46
>>438
羽生さんもいるくらいだからな。
441:デフォルトの名無しさん
04/10/08 11:00:56
>>439
で、ひがさんを擁護するフリをして、Seasar2は敷居が高い、とか、欠点に対する指摘を受け付けない、とかそういう逆宣伝をしてるわけか。
442:デフォルトの名無しさん
04/10/08 11:03:29
>>440
羽生さんがいるところには常に粘着するわけか。
大変だな。羽生さんも追っかけもｗ
443:デフォルトの名無しさん
04/10/08 11:04:03
恨みを買ってもしょうがないようなところあるからな。
人の話を遮って自分だけ延々と喋るし。
たいていは人の話に耳を貸さないくせにそれは相手によるし。
嫌いなやつは多いだろう。
444:デフォルトの名無しさん
04/10/08 11:07:09
>>443
まあそういう話はスレ違いってことで。
呼び出しくらうよ。
445:デフォルトの名無しさん
04/10/08 11:08:04
>>443
何だオマエ知り合いなのか。
本人に直接言ってやれよｗ
446:デフォルトの名無しさん
04/10/08 11:12:59
直接言えないから粘着してるんだよｗ
447:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/08 12:38:41
>>449
話をさえぎられて自分の出番を取られてしまった人じゃないの？
451:デフォルトの名無しさん
04/10/08 15:00:40
やられたらやりかえせｗ
452:デフォルトの名無しさん
04/10/08 15:17:48
>分からん奴らにはメソッドの仕様だけ渡して、
>その部分だけ他に影響を与えずに作らせることができるという
ちゃんと詳細設計ができてれば普通のOOPどころか構造化設計でもそうです。
ドキュメントがどうとかは(俺は言ってないけど)せっかく匿名で本音を吐いてくれてるのに
それを粘着呼ばわりする被害妄想は止めて欲しい
453:デフォルトの名無しさん
04/10/08 15:37:25
DIだと、影響を与えないための労力が少ない、ってことじゃね？
454:デフォルトの名無しさん
04/10/08 16:37:56
枠組みとして用意されているのでいろんなスキルの人がまざっても
平準化しやすい、という事なら納得できるけど。
というか詳細なインターフェース設計をしてからじゃないと実装始められないよ、
ということか。それはいいかも。でも実装し始めてから設計ミスを直すのが
めんどくさそうな肝汁
strutsがMVCモデルを強制してもActionにビジネスロジック書く奴がいて、
結局ちゃんとOOAしないとMVCのメリットがでない
↓
ちゃんとOOA出来る人がいたらstrutsの仕組み必要ない
(設定ファイルの手間が増えるし。taglibは便利だけど)
みたいな事にはならないのかな？全然Seasarの話じゃなくて申し訳ないが
455:デフォルトの名無しさん
04/10/08 17:04:12
DIというか、クラス名やらメソッド名を外部設定ファイルに埋め込むと、リファクタリング機能が効かないから不便かも。
strutsのMVCはアプリケーション全体でいえばVの中のローカルなMVCだからしかたないね。
456:デフォルトの名無しさん
04/10/08 18:15:12
>>453
YES
>>454
だからくーすを作ったんじゃないかな
457:デフォルトの名無しさん
04/10/08 19:38:28
>>448
>使う人は、実装を外注しやすくなり、Springと比べてもテストや
>設定が格段に楽になります。
まじ参考までに教えて欲しいんですけど、Seaser2がSpringと比べて
テストや設定がしやすい部分ってどういうところなんでしょうか？
SpringとSeasar2の比較をいろいろ探したんですが、どれもいまいち
ピンと来ないもので。
458:デフォルトの名無しさん
04/10/08 21:32:42
>>452
人をうんこ呼ばわりしてあげつらったヤシが
いるんだから被害妄想もある程度仕方ない
と漏れは思う。ひが氏の日記が大人しくなって
しまったのが個人的には残念だ。
459:デフォルトの名無しさん
04/10/08 21:39:32
議論のアンチパターン ～不毛な議論を避けるために～
URLﾘﾝｸ(homepage1.nifty.com)
460:デフォルトの名無しさん
04/10/08 22:59:10
外注というと書かれるコードの中身は汚くてもいいという印象があってよくない
461:デフォルトの名無しさん
04/10/08 23:06:46
外注はよくないけど、とりあえずS2について言うと、
欲しい機能を（Javaでやるという前提であるならば）考えられうる限りできるだけシンプルに実装できるもので
割と好印象。
462:デフォルトの名無しさん
04/10/08 23:10:56
少なくともJ2EEを作った香具師より頭いいのは確かだ
463:デフォルトの名無しさん
04/10/08 23:13:14
先にinterfaceありきと考えると
仮にコードが汚くてもUnitテストさえ
クリアしていれば安心が得られると
いう利点があるかなと思うけどどうかな？
464:デフォルトの名無しさん
04/10/08 23:18:59
>>463
テストをするのは当然で
汚いのはリファクタリングの原則に反するのでよくない
465:デフォルトの名無しさん
04/10/08 23:22:32
もちろんそうなんだけど
外注に出して汚いコード
だったとしてもまだ安心度が
保てるように思うんだが
466:デフォルトの名無しさん
04/10/08 23:27:35
設計は変わるもんだ。外注にやるとプログラマからのフィードバックが得られない。
S2は外注向けと考えるならそれは間違い。もともとソフトウェア開発はそういうものじゃない。
467:デフォルトの名無しさん
04/10/08 23:38:23
ほんとはみんなデスマが好きなのさ。
どっぷりとデスマに浸かることで、
自分は仕事をしているんだ！
という満足感が得られるからなのさ。
さらに、デスマを解消したり
回避する方法を考えるのは
もっと好きなのさ。
なんでかというと、
自分はこんなすごいことをやったんだ！
という優越感が得られるからなのさ。
Seasarってのはそうやって生まれたの。
468:デフォルトの名無しさん
04/10/08 23:39:03
外注に出さないプロジェクトって、小さなプロジェクトか小さな会社くらいでは？
469:デフォルトの名無しさん
04/10/08 23:45:27
>464
汚いのはリファクタリングの原則に反する、ってのはどういう意味？
リファクタリングの対象になる、ならわかるけど。
ついでにいうとユニットテスト通ってるならリファクタリングも気楽にできるね。
470:デフォルトの名無しさん
04/10/08 23:45:59
>>468
S2の話とはもう違うだろ。
外注に出すところのコスト構造って本当に酷いよ。
471:デフォルトの名無しさん
04/10/08 23:49:42
DI 使うとデバッガ使えないの？ テストうんぬんではなく、
ステップ実行とかできないの？
472:デフォルトの名無しさん
04/10/09 00:02:32
>>467
おかげでデスマにならずに済むなら漏れはありがたい。
>>471
S2のコードも全部放り込んでおけばいいんじゃない？
473:デフォルトの名無しさん
04/10/09 01:51:38
>>472
デスマはなくならないよ。
まず>>467でいう満足感と優越感がなくなっちゃうからね。
それに、新たな方法論を導入して解決するのは
「今までのステージにおけるデスマ」であり、
「次のステージにおけるデスマ」が控えているんだよ。
デスマあってのSeasarであり、
デスマある限りSeasatは進化し続け、
そしていつまで立ってもデスマはなくならない。
しかし、これがみんなの幸せにつながる。
474:デフォルトの名無しさん
04/10/09 02:18:01
＞デスマあってのSeasarであり、
( ﾟдﾟ)
(つд⊂)ｺﾞｼｺﾞｼ
(；ﾟдﾟ)
(つд⊂)ｺﾞｼｺﾞｼ
_, ._
（；ﾟ Дﾟ） …?!
'`,､'`,､('∀`) '`,､'`,､
475:デフォルトの名無しさん
04/10/09 02:58:52
>> 457
設定ファイルやテストコードを書くためのタイプ量がS2の方が少ない。
DIを使うと、これらの煩雑さが問題となってくる。
476:デフォルトの名無しさん
04/10/09 07:44:22
>471
DIは問題ない。初期化より後は普通だから。
でもAOPを使うとデバッガで追えない。
バイトコードいじってるやつ全般に言えることだけどね。
477:デフォルトの名無しさん
04/10/09 08:49:04
>>476
AOPを使っても追えるよ。
意味不明なクラスに行くけどそこもトレース実行すればその後は問題なかった。
478:デフォルトの名無しさん
04/10/09 14:05:50
>>476
デバッガで追えないのは、AspectJ。
S2は普通に追える。
479:デフォルトの名無しさん
04/10/09 15:42:43
>>462
J2EEっていうかEJB？
後だしじゃんけんだからなぁ。
DynamicProxyのおかげの部分もあるし。
480:デフォルトの名無しさん
04/10/09 16:24:41
>>479
S2はDynamicProxyは使ってないけどね。
cglibでバイトコードいじっているから同じようなものだけど。
481:デフォルトの名無しさん
04/10/09 16:54:24
・・・そうなんだね。
cglibのページの「Open source projects use cglib」に載ってないのが寂しいけど。
482:デフォルトの名無しさん
04/10/09 23:49:20
バイトコード操作してる地点で実案件に使えるのかなぁ。。
とても使わせてもらえなそうだが。。
483:デフォルトの名無しさん
04/10/10 01:01:18
オイオイ、どういう判断基準なんだ？
といことはcglib使ってるモノはすべてだめなんだね。
HibernateとかSpringとかも。
484:デフォルトの名無しさん
04/10/10 01:37:22
>>483
コンテナ部分は使ってないぞ。Spring。readme.txtに書いてある。
なので、AOPやDAO機能を捨てれば非バイトコード操作なDIコンテナとしては使える。
あと、PicoContainerも非バイトコード操作なDIコンテナだよね。
>>482
なので、あくまでもDIコンテナが使いたいならS2以外の選択もある。
AOPを利用したい時にはS2のほうが簡単だと思うけどね。
485:デフォルトの名無しさん
04/10/10 01:45:20
AOPなければ、意味がかなり減るんだけども。
SpringのAOP定義はめっさめんどり。
486:デフォルトの名無しさん
04/10/10 04:53:02
>>403
偉いなMS。蚊帳の外でもコミットしようとするなんて。
これだけ見るとSUNだめだな。
空のインプリメソッドがゴミのようにある俺のソース…。何とかしてくれ。
487:デフォルトの名無しさん
04/10/10 05:05:49
いろいろ考えたんだけどさ、EJBとかDIコンテナとか
やっぱりなんかくだらない気がしてきた。
アプリケーション毎に必要な機能って違うじゃんか。
（負荷分散・クラスタリング・動的再配置・トランザクション・必要になるパフォーマンス、とかいろいろ）
シンプルな実装をアプリケーション毎に作ったほうが、ムリヤリ共通して使える実装を探さなくてもいい。
488:デフォルトの名無しさん
04/10/10 05:07:32
シンプルに構造を分割する考え方（～層、とかいろいろ）の話を延々としているほうがいいと思うよ。
実装はアプリケーション毎に行こう。
489:デフォルトの名無しさん
04/10/10 05:15:47
>>455
リファクタをキジムナに期待age
490:デフォルトの名無しさん
04/10/10 05:23:48
>>487
それはアプリ毎に必要な機能じゃなくシステムの構成・設定。
487の言う「いろいろ」こそ共通して使える実装部分じゃろ。
491:489
04/10/10 05:56:56
>>330
> ところで、S2が正しくinjectionしてくれるかどうかの
> テストはどう書けば？（汗）
キジムナ使へば下に出るぞ。singletonだけかもしれんが。
それをキャプチャしたのをテスト結果とすると良いかも。
>>399
>>400
キジムナ使え。事前検証バリバリだぞ。
>>作者
コード補完機能ｷﾎﾞｿ
492:デフォルトの名無しさん
04/10/10 08:16:10
>>487
だから、アプリケーションごとに違う非機能要件をAOPを
使って処理するんじゃん。
493:デフォルトの名無しさん
04/10/10 08:30:30
>>486
俺もMSの態度は偉いと思う。
片思いなのがこれまた哀愁がただよってて
ヘンに共感してみたり。いやそりゃヨタだけども。
でもコーディング量が増えても
インターフェイスという考え方で統一したいって
気持ちもちょっと判るんだよねー。
494:デフォルトの名無しさん
04/10/10 08:36:10
>>490
トランザクションの基盤なんて単純なものならほんの数行のコードで実装できるし、
動的再配置するためのライブラリ（ちょっとしたネームサービス）あればいい
クラスタリングや負荷分散となると、それはアプリケーション毎にかなり違うもんだと思う
あんまり仰々しいフレームワークを用意されても、結局複雑にしてしまうだけではなかろうか
495:デフォルトの名無しさん
04/10/10 09:05:12
>>487
そんなこといったらJDBCもいらんってことにならんか？
何を持ってシンプルな実装というかだな。
496:デフォルトの名無しさん
04/10/10 09:41:42
>>494
ぎょうぎょうしいフレームワークって何。
S2はシンプルだと思うけど。
POJOが基本で、コアはDIとAOPの機能だけ。
コア以外の機能もいろいろあるけど、
使えるものは使えばいいし、無理に使わず自前で実装しても良い。
ただ、クラスタリングや負荷分散を自前で実装するやつは、
よっぽどのツワモノだと思う。
497:デフォルトの名無しさん
04/10/10 10:39:55
>>487
EJBはくだらないが、DIはくだらなくないよ。
アプリケーション毎に、というより、アプリケーション内で必要な機能をアプリケーション内で共通して使うためにDI+AOPが有効だと思われ。
498:482
04/10/10 12:58:13
>483
SpringもHibernateもDynamicProxyで代用できませんでしたっけ？
#フル機能使えなくてもさ
DIコンテナってテストが簡単とか、複雑じゃないとか利点ばっか挙げられてるが，
商用EJBコンテナが提供するような分散・スケールアウト手法は確立されているの？
499:デフォルトの名無しさん
04/10/10 13:02:41
>496
毎回毎回自分で実装できるような奴ならいらんのでしょ。
負荷分散・クラスタリング・動的再配置・トランザクションをシンプルな実装で
アプリケーションごとにバグ少なく作成できるような凄い人はうちの周りには
いないけどね。
500:デフォルトの名無しさん
04/10/10 13:10:21
>>499
負荷分散・クラスタリングって、パフォーマンスとの兼ね合いでいろいろ調整いるだろうから、
自分で実装っていうのが基本では。
それを補助く小さなライブラリ（タプルスペース扱うやつは便利だ）があれば満足。
501:デフォルトの名無しさん
04/10/10 13:18:19
>>500
スーパーな人発見。
釣りじゃないならすごいね。
そういうのは、アプリケーションサーバか負荷分散装置だとかに
任せるものだと思っていたよ。
502:デフォルトの名無しさん
04/10/10 13:21:07
まぁ、EJBとかに比べると仰々しくは無いのだけど、
Lightweightなプログラミング言語を使っているとどうしても大げさに感じてしまうのよね。
503:デフォルトの名無しさん
04/10/10 13:24:26
>>500
バイトコードいじくるものより、自分で組んだ負荷分散やらクラスタリングのほうがあてにならんなぁ。
トランザクションも、基盤は数行でも、いろいろなところに埋め込まれて、そっちの方があてにならんなぁ。
504:デフォルトの名無しさん
04/10/10 13:27:27
Lightweightなプログラム言語使ってる人って、ライブラリやフレームワークを勉強して数行でまとめて書けるコードを、頭使わず勉強せず数十行あっちこっちに書くほうが手軽だと思いがちだよねぇ。
505:デフォルトの名無しさん
04/10/10 13:31:12
>>501
貧乏人は自分で作るんですよ。多分。
506:デフォルトの名無しさん
04/10/10 13:32:18
スケールアウト、負荷分散いらないんじゃそもそもEJB使ってねえぞ。
これらの機能提供しないのに，EJBの代替物と歌われてもねぇ、、、
507:デフォルトの名無しさん
04/10/10 13:33:55
>>505
作っているものによると思うけどね。
一体どういうものを想定している？
HTML文章返すだけのウェブサーバとネットワークゲームのサーバではそりゃ負荷分散の手法は違ってくる
508:デフォルトの名無しさん
04/10/10 13:40:01
基本的に業務システム以外は対象外だからねぇ。
509:デフォルトの名無しさん
04/10/10 13:40:48
というか、ネットワークゲームのサーバーでEJBがどうのこうのいうほうが間違ってる。
510:デフォルトの名無しさん
04/10/10 14:26:38
>>509
そこはそれ、アプリ層のインプリだけ構造を統一するためにEJBの
スタイルを借りて、サーバー部分は最適化したものを自作、デスよ。
…ほんまかいな。
511:デフォルトの名無しさん
04/10/10 14:38:02
ネ申？
512:デフォルトの名無しさん
04/10/10 14:40:51
自ｲ乍ﾈ申
513:デフォルトの名無しさん
04/10/10 14:48:56
どの層で分散がいるかなんて、これはアプリケーション毎に違うでしょ？
どでかいコールセンターで検索したい人が多いなら単にデータベースを大量に水平に並べればよい。
核爆発シミュレーション計算の分散も基本的にはコンピュータ並べるが、自作率は後者のほうが多くなるだろうな。
514:デフォルトの名無しさん
04/10/10 15:03:27
>506
EJBの代替物とは謳ってないんじゃない？
J2EEの機能を使いやすくする、でしょ。
J2EE=EJBだと思ってるなら間違い。
ついでに言うとまだ発展途上なのに「全部無いなら使わん」とかいうならご自由に。
使いたいとこ、使えるとこだけ使えばいいんだ。
あとは自作なり他製品と組み合わせるなり。
515:デフォルトの名無しさん
04/10/10 15:06:12
語尾に「なり」をつけるやつは嫌いだ。
516:デフォルトの名無しさん
04/10/10 15:07:29
>>513
とりあえず対象となってない分野をもってきて、使えないとかわめくのって、悲しいね。
517:デフォルトの名無しさん
04/10/10 15:13:06
>>506
いつからEJBの主目的が負荷分散になったんだ？
518:デフォルトの名無しさん
04/10/10 15:14:39
EJBの代替物にもなってないしねぇ。
519:デフォルトの名無しさん
04/10/10 15:16:13
いや、当初から主要な目的の一つではあったが…。
負荷分散しないのにEJB使っても今ひとつ甘みが無い。
520:デフォルトの名無しさん
04/10/10 15:16:25
>>516
クラスタリング・負荷分散に共通して使える対象なんてありえないってことを示す例
521:デフォルトの名無しさん
04/10/10 15:18:24
業務システムに絞れば、共通して使えるしくみはあるんだけども。
で、とりあえずS2が話題にしてるのは業務システムなんだけども。
522:デフォルトの名無しさん
04/10/10 15:20:57
S2に限らずDIな連中が言ってるのは
EJBを使うのは大袈裟なシステムが
世の中には多いんだから別の手を
使おうぜってことでしょ。EJBが必要な
人はそっちを選べばいい。
523:デフォルトの名無しさん
04/10/10 15:21:36
まずは軽快なJavaを読めということでFAだな
524:デフォルトの名無しさん
04/10/10 21:28:23
それは負荷分散をしないって手？
525:デフォルトの名無しさん
04/10/10 21:35:31
負荷分散なんて、DBやアプリケーションサーバーにまかせればいいから、プログラムでは考えなくていい。
いくつかの注意点はあるけども。
526:デフォルトの名無しさん
04/10/10 22:39:39
APサーバに任せるメジャーな手段が、EJ(r
527:デフォルトの名無しさん
04/10/10 22:58:32
つか、なんかどーでもよいことに話がいってない？
負荷分散やらクラスタリングなんかDIコンテナで解決する問題じゃないし。
（てか、んなことまでサポートしだしたらLightweightなコンテナじゃなくなるじゃん）
もう少しS2自体の話があるとうれしいのだけど。
528:デフォルトの名無しさん
04/10/10 23:11:40
>>520
フレームワーク外の作りこみ一切禁止なんて縛りがあるわけでもないのに、
なぜそこで完璧を目指す必要があるのか理解できない。
パレート原則で言う8割の側を押さえるだけで十分では?
529:デフォルトの名無しさん
04/10/10 23:23:01
しってる難しそうな言葉をならべて賢くなった気になる遊びですた。
530:デフォルトの名無しさん
04/10/10 23:53:24
>>529
理解できない会話に無理に加わる必要はないよ、坊や。
531:デフォルトの名無しさん
04/10/10 23:56:29
2chだな～
532:デフォルトの名無しさん
04/10/11 01:57:15
>>527
> 負荷分散やらクラスタリングなんかDIコンテナで解決する問題じゃないし。
だってDIコンテナの作者らがEJBｲﾗﾈって言ってんだもん。
533:デフォルトの名無しさん
04/10/11 02:28:34
J2EEを使った業務システムで、そこまで必要なシステムって多くないし
その程度のシステムでEJBはイラナイだろ。
534:デフォルトの名無しさん
04/10/11 03:05:48
>532
DIコンテナの長所挙げるとき散々*EJB*と比較して、
難しいとか、テストが大変とかEJBの短点ばかり挙げるのにな（ｗ
535:デフォルトの名無しさん
04/10/11 04:37:42
遡ると、なぜJavaを選択するのかという話にならないか
短いコードで表現力の高いプラットフォームなら他にあるだろうに
536:デフォルトの名無しさん
04/10/11 07:14:54
>>532
負荷分散やクラスタリングは、ロードバランサや
HttpSessionでやった方が良い。
EJBでやるよりよっぽど実績がある。
537:デフォルトの名無しさん
04/10/11 07:38:11
>>536
HTTPって、それは単にウェブサーバの負荷を分散ではなかろうか。
素人なんだけど、業務アプリの場合、データベースのバックアップも兼ねた
クラスタリングが重要になるのでは？
538:デフォルトの名無しさん
04/10/11 08:13:38
>>537
C-JDBC使えば？
539:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/11 09:37:23
>>540
S2の用途は539の言うとおりだと思う。
S2が自分の用途に向かないなら他を探すのが良いと思う。
542:デフォルトの名無しさん
04/10/11 10:28:32
今のトレンドはStatelessだよな。EJBを使うにしてもだよ。
ということは負荷分散をEJBコンテナがやらなければならない
ケースは少ないといえるんじゃないのか。しかもHTTPだろ。
俺ならロードバランサを前に挟むけどな。
543:デフォルトの名無しさん
04/10/11 10:30:16
>>537
そういう場合は、DBの機能を使うよ普通。
OracleならRACとかな。EJB使うほうが当てにならん。
544:デフォルトの名無しさん
04/10/11 10:38:24
>>532
実際要らないシステムが多いだろ。デプロイが楽だからWeb使うだけで
大したトランザクション量じゃないシステムも多いよ。
>>534
そりゃそうだろ。DI自体がEJBに対するアンチテーゼだからな。
インコンテナのテストなんて面倒だろうに。
当のEJBだってPOJOに方向転換じゃないか。
EJB*だけ*がスケーラビリティ確保の手段だと本当に思ってるのか？
PHPで大規模やってる連中だっているだろ。そいつらが
どうやって負荷分散やフェールオーバを実現しているのかを見れば
EJBのレイヤーでなくてもやれることがいっぱいあるのはわかるだろ。
頭が固いか不勉強か単なる言いがかりかのどれかに見えちゃうぞ。
545:デフォルトの名無しさん
04/10/11 10:49:08
>>534
EJBの長所が負荷分散だというなら
それはEJBでなくても他に汎用的で
実績のある代替手段を使えばそれで
済むんだからEJBｲﾗﾈってことになるな。
EJBのテストが面倒なのは事実。
性能が出なくて変なテクニックばかり
横行するO/RマッピングもHibernateや
S2Daoのほうが便利で性能がいい。
EJB-QLなんて何の意味がある？
EJBの長所は何があるんだ？
DIがなくてもEJBにはウンザリしてるよ。
546:デフォルトの名無しさん
04/10/11 10:50:42
EJB擁護派はこちらで論破してきてください。
EJBは終わってる
ｽﾚﾘﾝｸ(tech板)l50
547:デフォルトの名無しさん
04/10/11 12:42:54
>>537
フェールオーバとロードバランスは別だよ。
でもってどっちもDIとかEJBとか関係なく
考えるべきものだから。クラスタリングは
EJBの専売特許ではない。
548:デフォルトの名無しさん
04/10/11 13:41:47
>540
「DIコンテナ」部分だけ使うなら、他を自作しても邪魔にはならないよ。
S2開発者が主軸に考えてるのがWebだってだけ。
周辺プロダクトはそれに合ったものからでてくるけど、別に必須ってわけじゃない。
業務機能と非業務機能を全部自作するにしても、DIコンテナで管理できると楽だ。
549:デフォルトの名無しさん
04/10/11 14:05:45
>>540
なんか、もっとすっきりできる気がするが・・・
550:デフォルトの名無しさん
04/10/11 14:52:49
diconファイルはシンプルだけど、それでもいろいろ書き間違える。
Kijimunaがないとやってられない。
Kijimunaってどれくらい使われてるんだろう。
SpringIDE(?)と比べるとどう?
551:デフォルトの名無しさん
04/10/11 15:02:57
>>550
「どれくらい使われているか」より「どれくらい使いやすいか」の方が大事
552:デフォルトの名無しさん
04/10/11 15:22:36
>>551
最新バージョンは使いやすいよ。
何が自動インジェクションされているかも分かるし、
コンポーネントの定義からソースにも飛べる。
553:デフォルトの名無しさん
04/10/12 01:45:36
Strutsでページ遷移の単体テストにS2Struts使うと楽になりますかねぇ？
554:デフォルトの名無しさん
04/10/12 07:30:29
>>553
なるよ。
555:デフォルトの名無しさん
04/10/12 21:58:53
JBossで座絶したんだけどこれ結構使える？
556:デフォルトの名無しさん
04/10/12 22:14:53
ちょっとずつ始めれるので、挫折しにくいよ。
557:デフォルトの名無しさん
04/10/13 00:04:53
何に挫折したのかを書くと世話焼きが相手をしてくれるぞ
Servletで挫折したならそれはJBossのせいじゃないからな。
558:デフォルトの名無しさん
04/10/13 02:59:31
インストールで挫折しますた。
559:デフォルトの名無しさん
04/10/13 03:04:47
ダウンロードに挫折しますた。
560:デフォルトの名無しさん
04/10/13 10:51:27
はぶにっき、訳分からん。突然切れチョル。
日記だからっちゅうても、雑誌に「S2はblog駆動」とか書いてるん
だから、何について言ってるんかハッキリするか、非公開にするか
せんと。
自分、さんざん内向きにアピールしちょるやないけ。
ひが氏が２chの戯言にまで耳を貸して、開発やドキュメント整備に
尽力しとるのを、足ひっぱっとりゃせんか？
車やコンピュータや家電だけが産業と違うじゃろ。
ハードウェア屋がコスト削る部分なんざ、ソフトでいえばコンパイル部分よ。
ここがこれ以上ないぐらい最適化されとるんやし、全品オーダーメイド
で、掛かる費用ほぼ人件費な状態を、車と一緒に考えられんわい。
「客に向け」「この業界に先はない」っちゅうんは至極まっとうだと思うが。
URLﾘﾝｸ(d.hatena.ne.jp)
561:デフォルトの名無しさん
04/10/13 10:53:23
メインフレーム時代からコストどれだけ下がったか。
562:デフォルトの名無しさん
04/10/13 10:59:26
>>560
あれは基本的に経営側の人間であって開発側の人間ではないのよ。
だから、経営の視点で開発の人間を判断して、当人としては歯がゆい思いを感じているんだろう。
といって、偉そうなこと言う割にはべつに経営で成功しているわけではないあたり、
文句たれている相手と同じ程度の人間であることをさらしてしまってるのだが、
それに気付いていない無知の無知がちょっとイタい。
563:デフォルトの名無しさん
04/10/13 11:16:17
>> 562
人格はどうでもいい。
564:デフォルトの名無しさん
04/10/13 11:27:28
つうか、はぶ氏個人の評価はスレ違い。
565:デフォルトの名無しさん
04/10/13 11:40:43
「経営側に回れるだけレベルは上」と考えてるんだろう、ある意味間違ってないが
566:デフォルトの名無しさん
04/10/13 12:00:24
>>560
URLﾘﾝｸ(capsctrl.que.jp)
ここへのコメントの続きじゃないの？
ここの人、若いんだけど、いっつも歯に衣着せぬ物言いなんで
（あ、若いからか）、いっつも微笑ましく読んでたんだけど
さすがはぶたんですなー、容赦せんもん。
上記サイトの人、今会計の仕訳の勉強とかしてるみたいで、
そういう勉強中の人に「DOAなんて否定的な表現」うんぬん言われると、
むちゃくちゃ厚い債権債務帳票とか出したり、
やったらきっつくて頭の切れる、出禁とかすぐ口に出すお客さんと
仕事した事あるのかなあ、と思ってたので、
ちょっとだけ溜飲が下がったよ。
はぶたん徹底して「顧客」って言わないね。お客様、と言う。
ちょっと気持ち悪くは感じたけど、プロなんだなとは思った。
567:デフォルトの名無しさん
04/10/13 12:38:18
まあなんつーか、たまに余人に見えないモノが見えてるヒトではあらぁね、
ソレが天才だからなのかデムパ受信してるのかはむろん余人に分かろうハズは無く…
ナニが言いたいかつーともーすこし他人の目を意識して書いてくださいと
＞金持ちに寄生して搾取してるだけじゃん。狭い世界の中で偉そうにしてるだけですよ。
＞OOもDOAも構造化も全員そうだよ。コバンザメでしかないよ。世界中が腐ってる！
568:デフォルトの名無しさん
04/10/13 13:02:47
コメント化って空のコメントがあるだけなんだけど
なんか書いてあったの？
569:デフォルトの名無しさん
04/10/13 13:14:31
相変わらず個人ネタか。
570:デフォルトの名無しさん
04/10/13 13:39:38
でも、お客にとっちゃOO分析だろうがER分析だろうが
知った事ではないだろうってのは、
くーすのよってたつ所なのではないかなあと思った。
だから本がどんなんなるか楽しみな訳で。
前に、見積もりの提示の仕方についても盛り込んでくれたらなーって
ここに書いたんだけど、それも上記が理由。
571:デフォルトの名無しさん
04/10/13 14:24:45
> 方法論がエンジニアにとって癒しにしかなってないじゃん、って思うんですよ。そりゃね、
> みんな賢いからさ、そういう人間が集まって膝突き合わしてそういうやり取りしてれば、
> 自分だけじゃない、って思えるしそりゃ楽しいでしょう。
> 別にS2でなければならない、ってこともないんですよ。EJBでも構わない。
> PHPでもRubyでもいいんですよ。
> 幾ら優れたことをやっても、根本的に「で？」としかならない。自分が一顧客として金を
> 出すとしたら、って考えると、欲しいのはそんな裏方の話じゃないっしょ。
これまた正論だが、日記でよく言うね。だが、あんたが自分でも気づかないフリしてる
心境は 「確かに S2 は良いかもしれない。ひがが目立つのはうれしいが、俺のほうが
できる人間なのにが影に隠れてるのはくやしい。」 だろ。
だいたい、客に伝わらんのはあんたの営業能力不足だろ w
古い言葉で言えば「バカの壁」だな。規模が違う話して悪いが、例えば IBM の研究所の
人間でもあんたは 「方法論ばかり言ってないで少しは経営のことを考えろ」 って言うか？
類稀な経営手腕を持ってんだったら、開発者に対してやる気なくすこと言わずに
気持ちよく駒として動かすことに専念すれば？ くーすﾏﾝｾｰとか言ってやれば
ドーパミン全開で土木作業してくれるよ w
多少、建設的なネタを。ひが君 「cglib 遅せーから Javassist 使う」 とか言ってないで
直接 ASM 使えよ。まー、バイトコードライブラリ作者は使う側のスキルはアテにしてないと
思うけどな。
性能： ASM ＞ Javassist（初心者向け） ＞ cglib(初心者向けASMラッパー)
＞ BCEL ＞ SERP
572:デフォルトの名無しさん
04/10/13 14:56:42
日記への反応は日記に書けば？あっちでも匿名で書けるんでしょ？
573:デフォルトの名無しさん
04/10/13 14:58:46
もしくーすがOOAなのかER分析なのかしったこっちゃないというなら俺は興味ないな。
システムの狭い世界での話であっても、OOAと構造化には明らかな壁があるのに
OOPLを導入してもその壁をうまく越えられてない人が結構いる。
くーすでクラス図もなしにバウンダリを基準に設計する(と読めたけど違う?)ものなら
壁を越えられない人たち向けには良い指針になるかもしれない。
前に使ったある外注は顧客クラスがあるにもかかわらず、
パスワード変更クラスとメールアドレス変更クラスをつくりやがった。
OOAでの1クラスが、複数のバウンダリに登場するのでバウンダリ基準はいくないと思う。
あと顧客が納得できるモノは画面イメージだけっていうのには諸手を挙げて賛同するけど、
顧客が仕様変更したがるのも画面なわけで、「やっぱり確認画面をいれたい」みたいな
変更要望に強くするためには、その後ろにあるクラス設計がいかに業務にマッチしているかが
重要になってくると思うんだけどお前らはどう思い松か？
574:デフォルトの名無しさん
04/10/13 15:37:37
別にさあ、日記に何かいてようがいいじゃん。
少なくとも、ここでどうこういう話じゃない。
プロダクトやプロモーションに関わることなら別として。
また呼び出しくらうよ？
575:570
04/10/13 15:37:50
>>573
「くーすが知ったこっちゃない」んじゃなくて、
くーすは「お客さんはそんなこと知ったこっちゃない」って
前提で考えられてるんじゃないかなーって
思ったの。
後半の、「顧客が納得できるモノは画面イメージだけって
いうのには諸手を挙げて賛同するけど」と同じでっす。
ちょっと言葉足らずでしたかすんません。
576:デフォルトの名無しさん
04/10/13 16:09:04
>「お客さんはそんなこと知ったこっちゃない」って前提で
なるほど。そうかも
その他の部分はひが氏の日記を拾い読みした記憶から勝手に脳内保管して
書いているので、見当違いだったらごめん、っていうか指摘してくだちい
577:デフォルトの名無しさん
04/10/13 19:01:57
しかしみんないろんな日記よく読んでるねえ。
みんななんだかんだいってもS2が気になってしょうがないんだね。
578:570
04/10/13 19:24:45
>>577
まさにそのとおり。からさわぎいくどー。
579:デフォルトの名無しさん
04/10/13 21:03:02
S2ってさ、ひがさん一人で開発してるんだよね？
開発者として、複数の人が参加して、互いにCheck&確認していった方が、
もっと、いい方向になると思うんだけどなぁ...
一人で開発してると...どうも、一人よがりになりそうで...
580:デフォルトの名無しさん
04/10/13 21:09:02
>>579
あれってオープンソースでやってて、独りで作っているわけじゃないでしょ？
S2Xxxって感じで他の人もやってたような…。
581:デフォルトの名無しさん
04/10/13 21:33:58
うちなーんちゅ記念ｶｷｺ
582:デフォルトの名無しさん
04/10/13 23:19:53
>> 580
コアな部分は全部１人でやってるよ。
583:デフォルトの名無しさん
04/10/13 23:43:03
S2Dao使うにはMySQLは不向きだな。
584:デフォルトの名無しさん
04/10/14 00:05:05
>>579
オープンソースの大半は最初はそんなもんじゃないの？使う人が増えて
パイが大きくなったらコントリビューターも増えるでしょ。
つかそうならないと増えないような
585:デフォルトの名無しさん
04/10/14 00:07:17
コアな部分はだいたいどんなプロダクトでもひとりでやってるもんじゃない？
コアとはいえ、全体からすれば一部分なんだし。
586:デフォルトの名無しさん
04/10/14 06:56:40
>>573
> パスワード変更クラスとメールアドレス変更クラスをつくりやがった
これの何が悪いのか。
これが適切な場合だって（むしろそのほうが）多いだろ。
587:デフォルトの名無しさん
04/10/14 06:57:10
顧客クラスにパスワード変更メソッド付けるなんてアフォとしか漏れには思えん
588:デフォルトの名無しさん
04/10/14 07:22:10
ケース倍ケースじゃん。
573のシチュエーションだと変に見えただけじゃないの？
589:デフォルトの名無しさん
04/10/14 16:25:45
顧客クラスというからには
cust.load();
cust.setPassword(pass);
cust.update();
とするだけで更新できるので、わざわざ別クラスつくる意味がまったくわからん。
顧客クラスにパスワードのバリデーションメソッドを追加するだけでいいのに。
わざわざパスワード変更用のクラスをつくってバリデーションと更新メソッドを
つくる意味を教えてくれないか？さらにメールアドレス変更クラスは
これにそっくりで、バリデーションの内容がちょっと違う(".@"が使える)のと
更新メソッドのsqlがちょびっと違うだけ。クラスの見通しも機能拡張への対応も
顧客クラスにまとめた方がはるかにいいじゃん。
是非俺にも納得できるように説明して欲しい
590:デフォルトの名無しさん
04/10/14 16:36:32
誰でも自由にクラスを作れて、
どんなクラスでもDBに自由にアクセスできて、
DBが間違いなく更新される以上なにも問題が起きない、
という無法状態を放置しているのがそもそもの間違い。
591:570
04/10/14 17:11:30
>>589
データと振る舞いをカプセル化するという方向は
実は間違いなんじゃないかという考えもあるんですよ。
エンティティは純粋にデータとしてとらえる。
意味がないわけではないと思いますよ。
ただそれもシステム全体の規模やルールとの兼ね合いも
あると思うので、杓子定規に当てはめるのもなあとも思う。
この場合は、印象のみだけど、ちょっと煩雑かなー。
592:デフォルトの名無しさん
04/10/14 17:54:51
>無法状態を放置しているのがそもそもの間違い。
まあそりゃそうなんだが。
>データと振る舞いをカプセル化するという方向は
実は間違いなんじゃないか
ちなみに今ウチでは顧客クラスでDataAccess顧客クラスを参照して
daoCustomer.setData(this);
dao.update(connection);
みたいな感じでDAだけ分離する方向です。小規模だとやらないけどね。Connection
渡すのは複数のDAにまたがってトランザクション管理するためね。S2DAOとか
使えば楽になるのかなあと思って興味を持ってるわけだけど。
で、パスワード変更やメールアドレス変更のために別クラスをつくって
似たような処理をいろんなクラスに書きまくった方が良いケースってのは
どんな場合よ？画面単位なので名前・住所・電話番号等の変更クラスは
一つにまとまってるんだろうけど。
「これらの画面を一つにまとめたい」とか「メールアドレスに対して
パスワードを送付する機能をつけたい」とかの仕様変更に対応するには
顧客クラスが汎用的に(といってもこのシステム内で、だけど)顧客情報を
管理できるクラスであることが重要じゃない？顧客検索みたいに顧客クラスの
インスタンスを複数扱う機能には、別に顧客検索クラスをつくるけどさ。
593:デフォルトの名無しさん
04/10/14 20:34:50
>>592
顧客情報と認証情報を別個に分けて管理したい時。
セキュリティのためにね。
>メールアドレスに対してパスワードを送付する機能をつけたい
顧客が希望しても、こういう仕様は止めろよ・・・
594:デフォルトの名無しさん
04/10/14 21:09:20
>顧客情報と認証情報を別個に分けて管理したい時
そのために内部の実装を分けないといけないようなケースがそんなにあるの？
>>メールアドレスに対してパスワードを送付する機能をつけたい
>顧客が希望しても、こういう仕様は止めろよ・・・
誰でもすぐ会員登録できる情報サイトなんかではこれでいいと思う。
つーか話題とずれてるけど
595:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/14 21:38:20
>>591
データと振る舞いを分離するって、Customerクラスと
CustomerLogicクラスに完全に分かれるってこと？
597:デフォルトの名無しさん
04/10/14 22:00:15
>596
で、CustomerLogic を具体的な業務ロジッククラスから呼び出して使えばいいのか。
白黒あいまいな感じで作りやすいかもしれない。
OOしてると、後だしででてきた要件の扱いに悶々と悩むことあるから。
598:デフォルトの名無しさん
04/10/14 22:07:20
下手するとDRY原則やぶりなコードができそうだな。
さらにS2Dao使うと、SQLの中にロジック散らばりそうだし。
599:デフォルトの名無しさん
04/10/14 22:16:47
データとロジック分けるメリットって？
600:デフォルトの名無しさん
04/10/14 22:48:16
>>599
メリットは597が言ってる。
でもそのメリットも、システム規模、それとクラスを分けた事による利用性や
他の利便性（DIのアーキテクチャにのりやすいとか他いろいろ）と
応相談ってところじゃないかな。
なんでもかんでもOO的にエレガントだからって押し切ると
業務要件とか実装上の現実問題とかないがしろにしちゃう。
パターンはパターンで有用だけど皆頭使おうぜって所ですか。
S2やくーすが、その頭使おうぜって所を
何処まで軽減できるかってのが、楽しみなところじゃない？
601:デフォルトの名無しさん
04/10/14 22:48:26
ValueObjectに処理を持たせるという話をしてるの？
602:デフォルトの名無しさん
04/10/14 23:01:23
>599
OOだと、組み替えたり、整理したり、やっぱこの部分独立させよう、いやいやそこはそのままで、
としてるそばからお客さんに「やっぱりおしごとのやりかたかえますた」って言われてイヤ。
ロジックとデータは分けておいて、diconファイルとかで業務構造を動的に管理するために
計算資源を使ったほうが合理的かも。
603:デフォルトの名無しさん
04/10/14 23:09:27
業務構造って、えらくあいまいな言葉だな。
データストア層とドメインモデル層を分けて考えるなら、おのずとDAOが出てくるわけだが。
604:デフォルトの名無しさん
04/10/14 23:16:36
S2JSFまだぁ？
605:デフォルトの名無しさん
04/10/14 23:21:26
>> 603
ドメインモデル層をデータとロジックに分けてしまおうって言ってんじゃないの？
ファウラー氏の言う「ドメインモデル貧血症」に。
606:デフォルトの名無しさん
04/10/14 23:40:01
601ハ、ValueObjectノ意味ヲハキチガエテマス。
607:デフォルトの名無しさん
04/10/15 00:33:00
>603
設計方法論に詳しいわけじゃないんで、変なこと言ってたらすまん。
処理の方法がころころ変わるような場合の話で。
ビジネスルールをそのままソフトウェアにしちゃいたい。
静的な構造はうまい人が作らないと汚くなるし、
完成するとそれで世界が完結するから変更が大変。
だからソースコードで書く部分をビジネスルール層だけにしてしまう。
それをO/Rツールが自動化してくれるデータアクセス層に被せる。
データは「ビジネスルールが正しく実装された」ことをテストして保障。
うまくいけば楽にならないかなぁ。
608:デフォルトの名無しさん
04/10/15 00:55:06
>>607
ふつーうにS2の実装ってそんな感じじゃないの。
609:デフォルトの名無しさん
04/10/15 03:00:24
ビジネスルールがSQLに分散するんじゃね？
610:デフォルトの名無しさん
04/10/15 09:44:02
ビジネスルールって言葉が曖昧だよな
611:デフォルトの名無しさん
04/10/15 13:35:54
>>609
どーせ、SQLは山ほど書くんだから問題なし。
612:デフォルトの名無しさん
04/10/15 14:09:21
>>611
山ほど書く中に分散したり、２重になったりがまずいんじゃ。。
SQLバリバリの人だったら、その辺問題ないのかなあ。
613:デフォルトの名無しさん
04/10/16 04:31:40
S2Ayaya を使えばあややのどこにinjectionできますか。
614:デフォルトの名無しさん
04/10/16 04:55:10
もちろん大事なところでしょう。
615:デフォルトの名無しさん
04/10/16 12:56:46
メタについてはどうよ？
実物がないからなんとも言えんが、
実装者への負担増えない？
616:デフォルトの名無しさん
04/10/16 14:25:56
>614
RejectedRuntimeExceptionが発生します。
617:デフォルトの名無しさん
04/10/16 21:29:13
>>591
>データと振る舞いをカプセル化するという方向は
>実は間違いなんじゃないかという考えもあるんですよ。
>エンティティは純粋にデータとしてとらえる。
>意味がないわけではないと思いますよ。
やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。
おまいら、以下を読んで目を覚ましてくれ。
----
ドメインモデル貧血症
URLﾘﾝｸ(capsctrl.que.jp)
このアンチパターンが根本的に怖いのは、オブジェクト指向設計の
基本概念（データと処理を一緒にする）の真逆だということです。
ドメインモデル貧血症とは、単なる手続き型設計のことなのです。
まさに、私（そしてEric）のようなオブジェクト信望者が、Smalltalkの
初期からずーーーーーっと戦ってきたもの、そのものなのです。
さらに困ったことに、貧血オブジェクト(Anemic Object) が本物の
オブジェクトだと思っているひとがたくさんいます。つまり、
オブジェクト指向設計が何たるかをまったく分かっていない
ということなんです。
----
618:デフォルトの名無しさん
04/10/16 21:50:51
そういう名前のアンチパターンがあるからといって、それが常に正しくないわけじゃないんだけどね。
619:デフォルトの名無しさん
04/10/16 21:57:31
>やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。
それは、一見ドメインモデルだけどそうではない、ってやつだろう。
591のは、もっと違う考えもあっていいんじゃないか、ってことで。
617は、世の中のソフトはすべて静的モデルで書くべきだ、という考えなのか。
620:デフォルトの名無しさん
04/10/16 22:49:27
構造化は一時期までかなーり成功を収めた手法だけれど、
OOってまだそこまで大成功は収めていない手法にも関わらず、
ここまで熱烈信者が増えてるのは何故だろう…？
621:デフォルトの名無しさん
04/10/16 23:09:46
591だけど、ドメインモデル貧血症の事は知ってます。
だけど、そういったゴリゴリオブジェクト指向マンセーな流れとは
別の流れも最近よく目にします、っていう意味ですよ。
世の中ファウラーの言う事だけが有用って訳ではないでしょう？
議論の余地があるみたいですね、って話です。
大体貧血症が怖い理由が、オブジェクト指向の基本概念と真逆だから
ってだけなのは、ちょっとお寂しいですね。
まあそのページを読むとファウラーさんは結構面白い文章を書く
おちゃめさんぽいので、半分ネタといか煽りの気もしますけど。
で、俺の立場としては、所詮DOA育ちなんで
基本的に貧血症大好き、
ただしメンテナビリティなどの事情を鑑みて、
責務割り当てるのもまぁありかなって所です。
そもそもその貧血症だのなんだの、
純血種しか許さない態度が俺は好かん。
622:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/17 01:50:08
DIともseasarとも関係ない話が続いてるけどなんか面白いな。
混ざってみよう。
これがすばり貧血症にあたるかわからないけど
URLﾘﾝｸ(www.relaxer.org)
エンティティの管理クラスが軒並み外出しになってる。どう？
はぶ氏も日記で「エンティティはDBのテーブル」と位置づけてたと思った。
意図的な極論なのかも知れないが、態度は貧血に近いと思う。
あとファウラーさんも「これはずいぶん昔からあるアンチパターンのひとつですが、
今になって台頭してきているようです。」って書いてるくらいだから
やっぱり貧血派は増えてるんではないすかね。
でもそんな違いは誤差だとかってまた言われそうだ。
627:デフォルトの名無しさん
04/10/17 02:07:30
あ、そうか、エンティティがDBのテーブルって事なら
ファウラーの言う所の「コスト」はかかってないって事か。
それにDTOと所謂ドメインモデルを合わせた
バリュー・オブジェクトって事も言ってますね。
ああ恥ずかしい。
628:デフォルトの名無しさん
04/10/17 02:25:12
まあ、DI、Seasar、くーすの流れだから、関係なくはないかな。
業務アプリ作ってる人全員が、上手いことOOで作ることは無理っていう
前提に、ICONIXやくーすってあると思う。
浅海氏のページ見たけど、要求分析から実装まで通して示してあって
いいね。とてもいい。
実装見ると、リファクタリングしたい（やっぱエンティティにもっとロジック
追加したい）って思うけど、上に書いた考えでいくと、酷い訳ではないし、
これっくらいが現実的なOOとのつきあい方かもしれん。
VB + OCXが割と正解だったってことかな。
629:デフォルトの名無しさん
04/10/17 03:37:46
626のサイト、とても勉強になりました。
ICONIXを基に、より包括的なプロセスになってる。
くーすは、ICONIXから無くしてもいいんじゃないかという部分を省いた、
軽いプロセスを目指してるんですね。ただ、常人には難しそう。
Relaxerプロセスを一通り実践して、カスタマイズしていくのが一番良さそうです。
Relaxer自体はどうだろう。自動生成のデータベースアクセスは重たそうだったけど。
完全にスレ違いになってしまいました。
630:デフォルトの名無しさん
04/10/17 09:05:34
>>629
どこが、常人に難しそうなの。
631:デフォルトの名無しさん
04/10/17 10:40:20
最近は、ドメインモデリングより、振る舞いのモデリングに
シフトしつつあると思う。
ドメインモデルはER分析した結果を使う。
(Entityとテーブルはほとんど同じ)
画面は、欲しい形でDTOとして受け取る。
DTOなので振る舞いを持たない。
DTOとEntityの相互変換をおこなうのは、
コストがかかるので、業務ロジック層や
データアクセス層で直接DTOを処理する。
これがくーすの考え方なんだと思う。
それを支えているのがS2Daoで、ほとんどコストをかけずに
DTOを処理できるようになっている。
632:デフォルトの名無しさん
04/10/17 11:06:45
> DTOとEntityの相互変換をおこなうのは、
> コストがかかるので、業務ロジック層や
> データアクセス層で直接DTOを処理する。
これは大きな間違いだと考える。
そのコストはオプショナルなコストではなく、必須のコスト。
必須のコストを減らす目的で他のマッピングツールを作ったほうがいい。
(DTO <-> Entity(≒ドメインモデル) を相互変換するような)
633:デフォルトの名無しさん
04/10/17 11:19:55
>>632
必須であるわけは。
業務ロジックは、画面のためにあるんだから、
画面に適したDTOを扱うのは自然だと思うけど。
634:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/17 12:04:21
>>634
ドメインモデルとDTOは、もともと一致するものじゃないと思うけど、
コストをかけても良いなら、
テーブル<->ドメインモデル<->View用のモデル(ViewHelper)
を相互変換しても良い。
きれいな設計というのはものすごくあいまいな言葉で、
自己満足にすぎない可能性もある。
内部スキーマ、概念スキーマ、外部スキーマの考え方は、
昔からあるけど、各スキーマの構造のミスマッチを解消するための
コストがかかるから、実際にはあまり使われていない。
637:デフォルトの名無しさん
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側に巻き込むかという二者択一となる。最近のひが氏は後者に
転んでいる模様。
# URLﾘﾝｸ(d.hatena.ne.jp) とか
ちなみに俺の上記のケースは細粒度のDomain Objectのトランザクション間
かつコントローラ間のロングキャッシュが非常に重要なドメインだったので
前者を選択したよ。
# ひが氏はロングキャッシュは知らんとか言ってるけど。
# URLﾘﾝｸ(d.hatena.ne.jp)
638:デフォルトの名無しさん
04/10/17 16:43:55
>>633
業務ロジックは画面のためにある、というのは違うでしょ。
画面の目的は２つ。
・業務ロジックを起動するための情報を収集する(=入力画面)
・業務モデルに関する情報を提示する(=参照画面)
639:デフォルトの名無しさん
04/10/17 17:35:07
>>637
よくわかる説明だけど、わかるやつにしかわからんってなってるかも。
640:デフォルトの名無しさん
04/10/17 18:18:33
>>638
それ、なにが嬉しいの？業務ロジックのために人は画面に情報を入力するの？
業務ロジックが画面のためにあるというのは違うと思うけど。
あくまで、印刷とか、ファイル転送とか画面をIFとしない業務ロジックもあると思うから。
>>633
こっちの方が正しいんじゃない？
641:デフォルトの名無しさん
04/10/17 18:49:29
>>640
>>638の1行目を穴が開くまで読むべし。
642:デフォルトの名無しさん
04/10/17 18:56:47
>>641
穴があいたら、次はどうすればいいですか？
643:デフォルトの名無しさん
04/10/17 19:01:05
>>642
入るしかないでしょ。
644:デフォルトの名無しさん
04/10/17 19:52:07
入れるしかないよ。
645:デフォルトの名無しさん
04/10/17 20:19:25
入れるから穴があくんだろ。逆転してるぞ。
646:デフォルトの名無しさん
04/10/17 23:33:54
はぶ氏の長文は、リファクタリング前のコードと同じ臭いがする。
647:デフォルトの名無しさん
04/10/17 23:59:45
俺らは研究者じゃなく、売り物を売ってんだから、新しかろうと古かろうと
コストが低く品質のいいソフトが作れる技術を選べってことだろう。
構造化もOOも上記を実現するためのものの筈だ。
清く正しいOOに固執するあまり、逆に生産性を下げて
しまってるのはマズいな。
ER分析と構造化手法に上手くOOのおいしいとこだけ取り込んでっていう
くーす的なやりかたが「今の時点」の正解だと思う。カスタマイズは自分らの
貯蓄に合わせてすればいい。
で、正しいOOの負の部分が解消されるようになれば（OODBの性能があがって安くなるとか）
すれば、それを使えばいい。
DIやAOP、ORMに関しても、効果と新しいコストとのバランスが重要で、
その点がS2が優れてるんだな。
ということで、Seasar2マンセー！S2Daoマンセー！S2JSFも（多分）マンセー！
648:デフォルトの名無しさん
04/10/18 00:09:33
まったく同意。本当、からさわぎ楽しみ。
でも仕事の頭からちょっと離れると、
やっぱファウラーの文章とか読むとワクワクするんだよね。
そんな自分も居るのが判ってるんで、ちょっと悔しいというか
さみしいというか。
だから617の気持ちも判るんだよなー。
649:デフォルトの名無しさん
04/10/18 00:10:53
リファクタリングして説教して来いｗ
みんなが>>646に期待してるぞ
650:647
04/10/18 00:30:39
>>648
>やっぱファウラーの文章とか読むとワクワクするんだよね。
その辺は先行投資だね。
関数型言語や形式仕様なんかも、そのままの形で仕事に使えないかもしれないが、
懐を広げておくのは開発者として重要だと思う。
ただ、いつの間にかその学習コストを客に押し付ける格好で、実案件に適用しようと
考えてしまう。
「この技術を使っています。だからこれだけ値段が上がります。」ってのは通用しない。
「この機能がこれだけ安く実現されます。」「この作業がこれだけ軽減されます。」
これを末端開発者も忘れないように気をつけたいね。
651:デフォルトの名無しさん
04/10/18 00:45:33
>650
ありがとう、なんか気が楽になりましたよ。
気が楽ってのは、けして安くない本を
会社の金でパカパカ買って乱読しちゃった
罪の意識が楽になった、って事だけど（w
652:デフォルトの名無しさん
04/10/18 00:47:45
まあ、スレ違いかもしれんが、こういった話無しにS2の良し悪しは語れんからな。
653:デフォルトの名無しさん
04/10/18 00:59:42
書籍代なんて誤差の範囲だよ。
プププ
654:デフォルトの名無しさん
04/10/18 02:34:48
結局、はぶさんは TransactionScriptでいーじゃんか、ってことか。
くーすもTransactionScriptをベースとしてんの?
655:デフォルトの名無しさん
04/10/18 02:46:23
>. 654
TransactionScriptだろうとMDAだろうと、今使えて、生産性向上とコストダウンを
実現できるやりかたでやるということだろ。客の利益になる物を作って、お金を頂いて
生活してることを忘れるな。
って、所詮2chか。S2にもフォーラムが欲しいな。
656:デフォルトの名無しさん
04/10/18 04:21:56
>>655
みんな各自のblogで満足してるから、実現性は低いね。
657:デフォルトの名無しさん
04/10/18 07:58:24
>>637
ドメインオブジェクトにViewHelper的な要素を
持たせるということなら反対。
むきだしのドメインオブジェクトなら、画面では激しく使いづらい。
658:デフォルトの名無しさん
04/10/18 09:28:58
>>655MLじゃ駄目なの？
659:デフォルトの名無しさん
04/10/18 15:53:43
>655
コイツはなに当たり前のこと偉そうに言ってるんだ？
生産性とコストダウンに加えて拡張性とメンテナンス性も向上させるのに
OOの中でもどういう手法をとったら効率がいいのか話あってるんだろ？
はぶか？
660:デフォルトの名無しさん
04/10/18 16:07:11
「客だよ、客！」
「利益なんだよ、利益！」
「コストダウンっつたらコストダウン！」
文脈を無視してこれしか言わないのはハブだろ。
じゃなければハブのクローンか。
661:659
04/10/18 16:08:44
どちらにしろ匿名で言い合っている中で人物名だす必要はなかったな。
あやまっときます。すんません
662:デフォルトの名無しさん
04/10/18 18:00:26
じゃあこれからは人物名「はぶ」ではなく機器名「Hub」ってことで。
663:デフォルトの名無しさん
04/10/18 18:56:32
納期とか予算とかがまずあって、手法はそのあと、とかそういう考え方って、サービス残業しろ、間に合わなければやっつけで、っていう考えにたどりつきがちだけどね。
ソフトウェアの開発は気合でうまくいくものではないと思うんだけど。
「客優先」「利益」「コストダウン」って、サービス残業させるための「魔法の合言葉」だね。
「やればできる。」
長期的に品質(含納期・予算)を確保するためには手法が必要だと思うんだよね。
手法にもてあそばれるのは良くないけど。
664:デフォルトの名無しさん
04/10/18 19:08:31
> 客の利益になる物を作って、お金を頂いて生活してることを忘れるな。
という考え方も、古いね。
サービスの対価としてお金もらってるんだから。主従関係ではないよ。
金額にみあったサービスを提供できればそれでいい。
それができないのは問題だけどな。
665:デフォルトの名無しさん
04/10/18 19:14:28
>>663
それははぶについてでなくて一般論だよね？
はぶは手法としてはくーすカスタムなわけで
サービス残業うんぬんの負荷の軽減を
言ってるわけで。
ほっときゃ本人があっちに書くか。楽しみにしていよう。
666:デフォルトの名無しさん
04/10/18 19:18:17
今の流れって前向きなの？ム板ですべき話なのかな？
技術のギの字も出さずにただ現場の話がしたいだけなら
マ板いけば？
って、所詮2chかｗ
667:デフォルトの名無しさん
04/10/18 19:34:01
俺はそんなにスレ・板違いにも思えないんだな。
S2からくーすにつながる中で
やっぱり現場の話は、どうしても出るよ。
それだけ実践的なものって事なんでしょう。
ムだのマだのでがっつり分けたがる方が
所詮2ch。
668:デフォルトの名無しさん
04/10/18 20:02:15
>>666
前向きもうしろ向きもなく、雑談。
669:デフォルトの名無しさん
04/10/18 20:03:18
マ板は、ネタスレ用隔離板ですよ。
670:デフォルトの名無しさん
04/10/18 20:04:47
現場の話が技術の話だと思わないあなたはピープルウェアでも読んでください。
671:デフォルトの名無しさん
04/10/18 22:29:15
ｽﾙｰしる
672:デフォルトの名無しさん
04/10/18 22:45:41
そんなことよりも S2JSF だよ。
まだでねーのかよ！
S2Flex とかどーでもいいからはやく S2JSF リリースして栗
673:デフォルトの名無しさん
04/10/18 23:39:08
OpenSymphony QuartzのJobにDIしたいと考えてるんだけど、タイミングが
つかめない。Jobインスタンスは実行ごとに生成されてそうだから、JobRunShell
でnewInstance()するごとにDIせねばならん。
Tapestryもそうだけど、元のライブラリがDIを考慮した設計になってないと
きついな。
674:デフォルトの名無しさん
04/10/19 02:32:25
はぶさんも、いちいち相手にしなけりゃいいのに。
「伝染るんです」のスズメみたいなもんなのにね。
675:デフォルトの名無しさん
04/10/19 03:31:31
おお、すずめかあ。懐かしいなあ。
でもピンポンダッシュっぽい感じもするので
「こらー！」ってゆってくれないとちょっと寂しい。
676:デフォルトの名無しさん
04/10/19 03:50:38
いやー、言いたいことをおもしろおかしく、語弊と誤解とあらぬ疑いをまじえながら、勝手に書き込んでるだけなんだよね。
2chってところは。
で、怒られたら逃げる。でもやっぱり離れたところでこそこそやる。
怒られなかったらそれはそれでちょっと寂しい。
677:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/19 21:23:49
>>678
StrutsやらHibernateやらいろいろ抽象化してくれるものと、DI+AOPのおかげで、極めて難しいというほどではないとおもう。
規模やら分野によるだろうけど。
681:デフォルトの名無しさん
04/10/19 23:15:00
この中の何人くらいがちょっとS2さわってみたとかではなく、
実案件でS2を適用し、かつ無事にリリースできているのでしょうか？
682:デフォルトの名無しさん
04/10/19 23:31:44
3.14人くらい？
683:デフォルトの名無しさん
04/10/20 00:10:39
S2というか、そもそもJavaで実装すること自体やめたほうがいい
684:デフォルトの名無しさん
04/10/20 01:06:05
なんで？
685:デフォルトの名無しさん
04/10/20 01:27:24
Jobの抽象クラスを作って、実行前にSingletonS2ContainerFactory.getContainer()
を呼ぶか。
686:デフォルトの名無しさん
04/10/20 01:29:31
S2コミュニティって、コアのおっさんたちは確信犯だろうから別にいいんだが、
周辺の若手マンセー君たちがイタイ。
何で「くーす=現場密着使える」「それ以外のOO方法論=机上空論使えねー」
って2分割の構図で思考停止できちゃうのかわからん。
# 逆説的に、2年前くらい前に「Togetherでラウンドトリップ」とか「永続化は
# EJB2.0CMPで決まり」とか「Struts最高」とか「Taglib凄い」とか言って
# 懐疑派を時代遅れの馬鹿扱いしてたやつらと同じ罠にはまってる気がする。
くーすは、素人だらけの現場でいかに一定の品質をキープするかという点
(予測可能性?)にフォーカスした、いわば極めて後ろ向きな方法論であって、
決して根本的な工数の削減やメンテナビリティにはフォーカスしていないと思う。
Transaction Scriptの欠点は単価安い下っ端ブルートフォース(+中国?)で
カバー、的な。
687:デフォルトの名無しさん
04/10/20 01:41:00
スレの流れとは関係ないが、なぜか同じ穴のムジナという言葉を思い出しちゃったな。
688:デフォルトの名無しさん
04/10/20 02:04:06
S2Daoに要望
・挿入時にAuto Incrementフィールドを
オブジェクトのプロパティで更新しないようにしてほしい。
・数値とbooleanの変換をして欲しい。
・countXXX(), sumXXX()なんかの集計関数の自動生成が欲しい。
・テーブル名、エイリアス名は`なんかで囲って欲しい。
・getLastInsertId()欲しい。
所詮２chなんで、さらっと無視して下さい。
S2JSF期待してます。
どうぞご自愛ください。
689:デフォルトの名無しさん
04/10/20 06:33:55
>「それ以外のOO方法論=机上空論使えねー」
ってあったっけ？
誰が若手やらわからんので俺が見てないだけかもしれんが。
690:デフォルトの名無しさん
04/10/20 06:39:58
>>686
TransactionScriptが
ロジックの共有化をはかると構造が複雑になる
と述べている理由を述べよ。
なんか、大きい仕事を任せてもらいない人が
思い込みで語っているような。
あなたにまかされたプロジェクトが、いかに効率的
なのか説明してみよ。
691:デフォルトの名無しさん
04/10/20 09:19:09
S2Quartz!!!
URLﾘﾝｸ(d.hatena.ne.jp)
692:太田＠会社
04/10/20 12:05:09
686さん>
「若手マンセー君」はWithout EJBの勉強会に参加して見回した限りは
(本当はRUP推進派の)僕も含めて存在しないです。僕自身の立場としては
限られたりソース内での最大限の効果を望む社内のDOA(Data Oriented
Approach)な人にも使っていただけ，単体テストが効率化する「くーす」と
Seasar2(および周辺プロダクト)を応援しているというだけで，マンセー
ってわけではないです。理想は，でも現実的には，だったらどうしたらよい
という前向きな人たちの集まりだと思うのだけど。そうじゃなかったら休日の
半日つぶして勉強会に集まったりしませんよ。
693:デフォルトの名無しさん
04/10/20 13:08:35
>>686
>2分割の構図で思考停止できちゃうのかわからん。
思考停止しているのは、あ・な・た☆