トップページ⇒tech
1001コメント305KB

国産DIコンテナSeasarとくーす その４

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2005/06/24(金) 19:23:41
一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ？みんなもう使ってるの？
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。

あと、開発プロセス「くーす」の話題もこちらでどうぞ。

本家 seasar.org
http://www.seasar.org/

Seasar Projectグループ
http://seasarproject.g.hatena.ne.jp/

ひがやすをblog
http://d.hatena.ne.jp/higayasuo/

前スレ
その１　http://pc5.2ch.net/test/read.cgi/tech/1092044210/
その２　http://pc5.2ch.net/test/read.cgi/tech/1098885253/
その３　http://pc8.2ch.net/test/read.cgi/tech/1102862221/

関連スレ(なのか?)

Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/

Dependncy Injectionを語るスレ
http://pc8.2ch.net/test/read.cgi/tech/1099827125/
0079デフォルトの名無しさん2005/07/06(水) 15:29:01
>>78
会社で見たくなるような内容がなくなって久しいと思うが
実はアイドル目当てで見てるだろw
0080デフォルトの名無しさん2005/07/06(水) 19:53:46
長文よんだ。
要は試してもいない方法論の出版を企画して、執筆中に気が変わっちゃったんでしょ。
よく知らないけど、出版業界ってそんな企画倒れでもＯＫなんすかね。

没になったのはよかったと思う。
もし出版までこぎつけてたら、数千円だして本買って執筆者のＢＬＯＧ見たら
「あの本の内容、実際の開発で試してみたら、よくないところが色々見つかっちゃった」
とか書いてあって「今くーす２っての考えてます。全然別物なんで名前も変えます。GOYAです」
とか発表されちゃってて。
そりゃねーっすよと。洗練させてから売れよと。

幻のくーす本の帯にはどんな煽りコピーがついたんだろうか。
0081デフォルトの名無しさん2005/07/06(水) 20:25:08
それだと大半の技術書はすぐに陳腐化するから売れないと思う
0082デフォルトの名無しさん2005/07/06(水) 20:29:07
Goyaもくーすと同じ道をたどるのか
0083802005/07/06(水) 20:41:25
>81
当初の出版予定が３月か４月だろ。
３ヶ月ほどで著者本人が「ありゃもう陳腐化しちょる」は無いよ。
しかも正しく「机上の空論」だった訳で。
0084デフォルトの名無しさん2005/07/06(水) 20:55:00
まぁ所詮はEJBが重い頃に生まれた仇花、一時の流行り物に過ぎなかったと。
3.0登場で役割を終えた訳で。
0085デフォルトの名無しさん2005/07/06(水) 21:03:14
今まで、くーすを担いでたアフォは良い面の皮だな。
0086デフォルトの名無しさん2005/07/06(水) 21:09:02
Martin Fowlerのアナパタ本は先駆的だと感じたが、
PoEAAは充分過ぎるほど充分に現場で確かめられた、陳腐化した内容だと思う。
そして陳腐化こそが、工学なのだと思う。

でまかせ開発方法論が未然に防げたのは、とても良いニュースだ。
0087デフォルトの名無しさん2005/07/06(水) 21:31:57
結論：やっぱウォーターフォールで構造化プログラミング。これ最強。
0088デフォルトの名無しさん2005/07/06(水) 21:44:27
頭おかしいのはスルー。つかてめぇ語尾にちゃんと全角ダブリュー小文字つけろよ
0089デフォルトの名無しさん2005/07/06(水) 22:01:40
↑
追跡妄想、乙。
0090デフォルトの名無しさん2005/07/07(木) 02:50:24
Blogや雑誌記事閲覧、S2+S2DAO+S2JSFの調査での印象
・永続層がプレゼンテーション層に依存する
・永続層にビジネスロジックが散らばる
・DAOの実装(SQL)だけが肥大化しそう
・複数RDBMSに対応することがよくあるので、リッチなSQLは避けたい
・ビューやストアドは簡単に作ってもらえない場合も多い

永続層もバウンダリとして捉えて何か考えてみることにする。
0091デフォルトの名無しさん2005/07/07(木) 08:59:53
ここはあなたのメモ用紙じゃないよ。
いくつかの誤解と、単なる趣味的な選択(もしくは前提を崩す話)が入っているような気がする。
0092デフォルトの名無しさん2005/07/07(木) 17:16:06
>>90
> ・永続層がプレゼンテーション層に依存する
> ・永続層にビジネスロジックが散らばる

なにを根拠にそう思ったの。
0093デフォルトの名無しさん2005/07/07(木) 18:18:11
>>エピソード3
誰が誰なんだかはよくわからんが、
事の顛末をすごく分かりやすく説明してるような気がする。

やっぱり宣戦布告はくーす本に関係してたんだ。


で、>>80がダースシディアス？ｗ
0094デフォルトの名無しさん2005/07/07(木) 18:38:17
方法論の進化を、どう方法論に取り込むのか？という高尚な話題かと思ったら、
なんだ単なる内輪喧嘩で没で手打ちか。・・・いかにも業務系っぽい玉虫色痒尻だ
0095デフォルトの名無しさん2005/07/07(木) 20:21:59
暗黒卿は普通の顔してやってくる。

今後は気をつけるこった。
0096デフォルトの名無しさん2005/07/07(木) 23:48:54
akonは普通の顔してやってくる。

今後は気をつけるこった。
0097902005/07/07(木) 23:49:55
>>92
SQLの結果セットを直接DTOにマッピングするからです。
ビジネスロジックではなく単にロジックと言った方が良かったですね。
過去スレやBlogでも議論されていたと思います。

ロジックの分散については比嘉氏の日記でもデメリットとして言及されていますし、
初期は「プレゼンテーション層の構造は閉じているべき」という主張だったと
思います。後にDTO,Entityの変換コストを減らすため、DAOで直接DTOを扱うように
なりました。

これはこれで他の利点とのトレードオフとなると思いますが、くーすからGoyaへ
移行の中で、実案件でのフィードバックをふまえ、どのようになったかが気になります。

>>91
どの点を誤解しているとお考えでしょうか。
くーすあるいはGoyaがどのような前提を設けているとお考えでしょうか。

複数RDBMS対応や、ストアド等の作成権限を持たないというのは
趣味的な選択ではなく、WEBシステムで一般的にありえる状況だと思います。
0098９１2005/07/08(金) 00:58:44
>>91は失礼。
「印象」というだけあって、感じたままを書いているだけなので、
主語や問題点がよく見えず、どのような対策や改善案を想定すべきなのか、
皆目見当が付きませんでした。

> いくつかの誤解と、

　　SQL結果セットをDTOにマッピングする処理を、
　　ロジックと呼ぶ人を初めて見ました。

　　Seasarについて良く知らないのですが、
　　DAOとDTO、永続層とプレゼン層の連携を優先するあまり、
　　両者を切り離す設計は選択できないようになっている、という事ですか？
　　前者(DAOとDTO)は、データ量によってはメモリ消費や分散通信コストにインパクトがありそうですし、
　　後者はなんか手書きの分量が増えそうな印象を持ちました。

> 単なる趣味的な選択(もしくは前提を崩す話)
　>>90
　> Blogや雑誌記事閲覧、S2+S2DAO+S2JSFの調査での印象

　>>97
　> くーすあるいはGoyaがどのような前提を設けているとお考えでしょうか。

　S2+S2DAO+S2JSFの話に、何故、前提として方法論が出てくるのか、
　Seasarを良く知らない私には意味がわかりません。

　察するに最後の黒ぽち三つは、フレームワークがDBMSとのマッピングを重視するあまり、
　DB管理者が嫌がるような設計が、DBMS側に必要とされるので困る、という話でしょうか？
0099デフォルトの名無しさん2005/07/08(金) 00:58:55
永続層っつうかDTOがプレゼン層に引きずられるのは気になっている点ではあるが、「単なる詰め替えレイヤは無駄」
という主張にも一理あるような気が。正直何とも言えん。

あとSQL結果セット指向、SQLで出来ることの縛りを少なくしようっつうのがS2Daoの基本思想だと思うのだが、
それだとリッチSQLマンセーなのは仕方ないかと。嫌ならHibernateの方がいいかも知れず。
0100デフォルトの名無しさん2005/07/08(金) 01:00:55
>>99
同意。
マッピングのやりやすさを重視するあまり、
マッピングの途中に何か処理をかまし、選択的マッピングをする、という処理が
記述しにくいという話なのかと理解しました。
0101デフォルトの名無しさん2005/07/08(金) 11:35:53
A卿の話は、違ってたら否定されると思ってたんだけど、否定されないね。
0102デフォルトの名無しさん2005/07/08(金) 17:04:34
結論：暗黒卿＝akon卿
つうかakonって何者？
ただ翻訳してる人じゃないんだ？
0103デフォルトの名無しさん2005/07/08(金) 18:40:35
・・・妄想性の精神病患者さんでつか？
　　はやく病院に戻った方がいいでつよ。
0104デフォルトの名無しさん2005/07/08(金) 20:06:53
個人を特定する記述があるのに誰も否定しないのは
それが事実だからだと妄想している俺がいる
0105デフォルトの名無しさん2005/07/08(金) 20:14:22
くーすについて、h(1)の伝聞ではなく自分の考えを書いてた時期もあるよね。
0106デフォルトの名無しさん2005/07/08(金) 20:30:33
つうか何の情報もないのに暗黒卿確定かいw
0107デフォルトの名無しさん2005/07/08(金) 21:41:10
まあ2chだし。
0108デフォルトの名無しさん2005/07/09(土) 02:28:39
akon=arton
0109デフォルトの名無しさん2005/07/09(土) 02:37:38
akon=あぼ〜ん
0110デフォルトの名無しさん2005/07/09(土) 02:38:16
キチガイ降臨
0111デフォルトの名無しさん2005/07/09(土) 04:48:53
>>108
それはさすがに違うんでねーの？
0112デフォルトの名無しさん2005/07/09(土) 14:49:35
特定非営利活動法人Seasarファウンデーション

(1) 団体会員 年会費１口300,000円（１口以上）
(2) 個人会員 年会費１口1,000円（１口以上）

ttp://foundation.seasar.org/

ヲチしているヒマなあなた！よろしく
0113デフォルトの名無しさん2005/07/09(土) 17:13:40
ひょっとしてマンダラート絡みか? > 暗黒卿

0114デフォルトの名無しさん2005/07/09(土) 17:28:56
個人会員になって、握手してもらうZE！
0115デフォルトの名無しさん2005/07/09(土) 18:59:50
「ここにすべての答えがあった」 "セックス教団"の「帝國主義大作戦」明らかに
http://news19.2ch.net/test/read.cgi/newsplus/1120640542/
0116442005/07/10(日) 03:05:55
http://d.hatena.ne.jp/higayasuo/20050708#1120801919

> そのクラスの頻繁に変更される部分を別のクラスに分離してしまえば、
> もとのクラスは安定して修正が入ることはなくなります。

これはOKなのですが

> 極めてあたりまえのことを言ってるように思われるかもしれませんが、
> 実はあまり守られてはいないと思います。その原因は、「関連のあるデータと
> 振る舞いを1つにまとめることがオブジェクト指向だ」とする強い思い込みです。
> 頻繁に変更される振る舞いを別のクラスに分離すると、オブジェクト指向的では
> ないと思ってしまうのでしょう。

これについては2点ほど気になるところが。

1)
「データと振舞いを1つにまとめる形式」でも頻繁変更箇所の別クラス化はできます。

2.)
> 頻繁に変更される振る舞いを別のクラスに分離すると、
> オブジェクト指向的ではないと思う
のではなく、
データと振舞いを分離すること、つまりカプセル化を壊すことがオブジェクト指向の
ベースとなっている抽象データ型の考えに沿わないためにオブジェクト指向的ではない
と感じるのです。
0117デフォルトの名無しさん2005/07/10(日) 03:19:41
これも
ttp://d.hatena.ne.jp/higayasuo/comment?date=20050629#c
華麗にスルーされているが「揚げ足とるなよ」って感じか？
0118デフォルトの名無しさん2005/07/10(日) 03:46:38
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?InversionOfControl
> 最近、IoCコンテナの盛り上がりにより、制御の逆転の意味をめぐっていくつかの混乱がある。
> ここで挙げた一般的な原則を、依存性注入(dependency injection)*1のような特化したスタイルの
> 制御の逆転と混同している人がいる。

これに対しての意見をうかがいたい。
0119デフォルトの名無しさん2005/07/10(日) 04:16:44
>>117
実際、DIのしくみをつかうことでAOPが実現できてるんだからいいんでねぇの？
0120デフォルトの名無しさん2005/07/10(日) 04:58:20
別にAOPの実現にDIの仕組みを使ってるわけではないだろう
ただDIには「インジェクトする」というタイミングが必ず発生するので、アスペクトを適用しやすい、
つまり親和性が高いだけの話で、概念としてはわけないと。

DIがなくたってAOPは実現できるんだから。
01211172005/07/10(日) 05:07:02
「Seasar2 の AOP は DI で実装されている」ってこと？
それなら、気持ちはわからんでもない。

でも >>120 の言うように、DI がなくても AOP は利用できるよね？
0122デフォルトの名無しさん2005/07/10(日) 05:12:08
この意見もどうなんだろうな。もまいらの釣りか？
ttp://d.hatena.ne.jp/higayasuo/comment?date=20050629#c
『本だけで勉強していると「オブジェクト指向=ドメインモデル」というイメージが強いのですが、
　ごーやの場合は、PofEAAでいうところのサービスレイヤ(実装バリエーションが操作スクリプト手法のやつ)
　を使用していると言っていいのですかね。』

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel
0123デフォルトの名無しさん2005/07/10(日) 05:12:18
DIがなくてもAOPを利用できるけど、AOPを使うためにはなにか仕組みが必要で、DIはその仕組みのひとつ。
DIがAOPを使うための仕組みのひとつである以上、DIを使えばAOPが使えるというのは間違いではないと思うが。
DIを使わないなら、なにか他のしくみを使ってAOPを実現しないといけない。
0124デフォルトの名無しさん2005/07/10(日) 05:13:50
↑URL間違えた

この意見もどうなんだろうな。もまいらの釣りか？
http://d.hatena.ne.jp/higayasuo/20050708#1120801919
『本だけで勉強していると「オブジェクト指向=ドメインモデル」というイメージが強いのですが、
　ごーやの場合は、PofEAAでいうところのサービスレイヤ(実装バリエーションが操作スクリプト手法のやつ)
　を使用していると言っていいのですかね。』

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel
0125デフォルトの名無しさん2005/07/10(日) 05:16:17
>>123
DI、AOPで実現できる事の包含関係と、実装方法を混乱して理解している。

　　DIで実現できる事　　⊂　AOPで実現できる事


　　DIの実現方法の一つ ⊂　AOPの実現方法の一つ
0126デフォルトの名無しさん2005/07/10(日) 05:16:31
基本的にはPofEAAのパターンを使った実装方法だからなぁ。
0127デフォルトの名無しさん2005/07/10(日) 05:17:12
>>125
なんか勘違いしてねぇ？
0128デフォルトの名無しさん2005/07/10(日) 05:23:02
DIで実現できることはAOPで実現できることに完全に含まれてるわけじゃないね。
というか、ちょっとしか共通点ないんじゃないの？

それに「〜の一つ」って「⊂」の項に置いたら集合演算にならんでしょ。
0129デフォルトの名無しさん2005/07/10(日) 05:25:34
＞DIで実現できることはAOPで実現できることに完全に含まれてるわけじゃないね。
＞というか、ちょっとしか共通点ないんじゃないの？

ほう。じゃ含まれていない部分を挙げて下さい。

＞それに「〜の一つ」って「⊂」の項に置いたら集合演算にならんでしょ。

DIとAOPのつながりは、その部分しかないでしょ。
「〜の一つ」は Existという意味じゃなくて、指示代名詞です。

0130デフォルトの名無しさん2005/07/10(日) 05:25:38
Seasar2 自身が 「DIコンテナ＋AOP」を名乗ってるのに DI にひっくるめちゃうのか。
01311172005/07/10(日) 05:26:48
>>125
わかりにくい
0132デフォルトの名無しさん2005/07/10(日) 05:28:05
DIとAOPの件は、ためにする議論でしょ。あんま有益な意見は出ないと思う。つかDIって持てはやされすぎ。

むしろ、>>117, >>118, あたりのトラックバックに関して、
ご本人のコメントが付く前に場外乱闘を繰り広げるのが、
２ちゃんらしいやり方だとおもう。
0133デフォルトの名無しさん2005/07/10(日) 05:29:01
DIとAOPの件は、ためにする議論でしょ。あんま有益な意見は出ないと思う。つかDIって持てはやされすぎ。

むしろ、>>116, >>117, >>118, あたりのトラックバックに関して、
ご本人のコメントが付く前に場外乱闘を繰り広げるのが、
２ちゃんらしいやり方だとおもう。
0134デフォルトの名無しさん2005/07/10(日) 05:29:24
>>129
つうか、「⊂」の意味わかってる？
>>125の下側の式は、型エラーだよ。
コンパイルエラーのある意見には、説得力ないんだけど。
01351172005/07/10(日) 05:32:53
記号逆じゃない？

Java ⊂ プログラミング言語


0136デフォルトの名無しさん2005/07/10(日) 05:41:49
「⊂」は、両辺が集合じゃないといけないのさ。
だから
　オブジェクト指向言語⊂ プログラミング言語
とかになる。
　Java ∈プログラミング言語
の方が正確な表現。
べつに厳密な表現もとめてないから
　Java⊂ プログラミング言語
でもいいと思うんだけど
　Java⊂ プログラミング言語のひとつ
だと明らかに誤り。
論理的な考えが苦手な人のようにみえてしまう。
0137デフォルトの名無しさん2005/07/10(日) 05:42:15
>>134
あなたには、実装方法のバリエーションと総称のことなど全然理解できないのだと思う。

しようもない小粒なガキだ
0138デフォルトの名無しさん2005/07/10(日) 05:43:56
>>128
＞というか、ちょっとしか共通点ないんじゃないの？

このフレーズは同意。
つか、場外乱闘ってゆーより、隠居の小言れべるのショボさだな、
この時間帯に常駐しているのわ。
0139デフォルトの名無しさん2005/07/10(日) 05:45:56
DI：　　依存性注入
AOP： 共通的な関心事(観点)の切り出し

２ちゃんに流布されている誤った意見
　「SeasarはDIによってAOPを実現している」

　　　　　　　　　　　　　　　　　　　　　　　　いじょ
0140デフォルトの名無しさん2005/07/10(日) 05:51:37
>>139
じゃあ何によってAOP実現してるの？
AOPっていう言葉を、メソッドの前後に処理を埋め込むっていう狭い意味ではなくて、広い意味で扱えっていう話？
0141デフォルトの名無しさん2005/07/10(日) 05:54:59
DIって単にインタフェースに対する実装クラスの対応付けを行うための技術だろ。
なんで 「DIでAOPが実現できる」なんてトンでも意見を繰り返す人物が居るのか、
まったく理解できない。。。

え、もしかしてAOPのAspectをあらかじめInterfaceとして作りこんでいて、
そこに実装を突っ込むって・・・？？！それは正に、

　　AOPで意図している事を、DIでもっと劣った方法で実現する

だろ
0142デフォルトの名無しさん2005/07/10(日) 05:57:40
・PointCutをAnnotationで指定
はアリとして、
・PointCutをInterfaceとして作りこむ
って激しく面倒だな。メソッドレスのinteface (Serializableとか)じゃ、ほとんどDIとして機能しないし。
0143デフォルトの名無しさん2005/07/10(日) 05:58:46
Seasarの実装とか文化がインタフェースを積極的に使うというだけで、DIはインタフェースに限らんよ。
別にコンクリートクラスをセッターに突っ込んでもいいし。
0144デフォルトの名無しさん2005/07/10(日) 06:01:18
なんか疲れてきた。
0145デフォルトの名無しさん2005/07/10(日) 06:01:35
>>144
おやすみ〜
0146デフォルトの名無しさん2005/07/10(日) 06:02:29
> 別にコンクリートクラスをセッターに突っ込んでもいいし。

おそらくこの文は、意図している意味とことなった字面になっていると思う。
何を意図されているのか、ご説明願えますか？
0147デフォルトの名無しさん2005/07/10(日) 06:03:27
あ、そうかも
セッターの引数がコンクリートクラスでも構わないということ。
0148デフォルトの名無しさん2005/07/10(日) 06:03:59
インタフェースなんて空気のように使うもんだから、

> Seasarの実装とか文化がインタフェースを積極的に使うというだけで、DIはインタフェースに限らんよ。

このフレーズには激しい違和感を感じる。もしかして、プログラム書かない人？
あと、DIでインタフェース以外というと、抽象クラスですか。
0149デフォルトの名無しさん2005/07/10(日) 06:04:34
>>147
もっと詳しく。なんか勘違いしている人だと思う。
0150デフォルトの名無しさん2005/07/10(日) 06:06:02
>>149
ひとつもインタフェース定義しなくても、抽象クラス定義しなくても、実装によってはDI使えるってこと。
0151デフォルトの名無しさん2005/07/10(日) 06:06:25
>>129 回答まだぁ〜？（ﾁﾝ、ﾁﾝ　☆
0152デフォルトの名無しさん2005/07/10(日) 06:08:08
>>150
ああ判った判った。サブクラスを入れ込むってだけの話ね。
最初っから不毛な「AOPをDIで実現する」っつう与太話で敗色が濃くなってきたから、
局地戦で屁理屈捏ねだしただけね。しょーもな。
0153デフォルトの名無しさん2005/07/10(日) 06:09:29
>>152
サブクラスである必要もないんだけど。
0154デフォルトの名無しさん2005/07/10(日) 06:11:16
バカは放置するとして。

>>116, >>117は悩ましいな。
マジレスするにはとてつもない集中力が必要だ。
しかも本家の方は本人のコメント待ちだから、うかつにレスつけらんないし。
0155デフォルトの名無しさん2005/07/10(日) 06:12:23
また一行レスの中身無い人が粘着してるな。
>>153
じゃなんだ。ちゃんと詳しく説明してみろ。
また一行レスではぐらかすようだったら、今後一切お前は書き込むな
0156デフォルトの名無しさん2005/07/10(日) 06:13:11
なんか、自分の考え方と違うこたえがでてきたら「バカは放置」ですか。
やっぱ、論理的な考え方になれてないから論理的につっこみ入れられないんですね。
0157デフォルトの名無しさん2005/07/10(日) 06:14:40
>>155
class A{
}
のオブジェクトを
class B{
void setA(A a){
　　this.a = a;
　}
}
にインジェクション可能なDIコンテナもあるってこと。
0158デフォルトの名無しさん2005/07/10(日) 06:15:05
>>155
どーせリフレクションでメソッド調べて、
継承されていないクラスを総称的に扱うとか、
そんなレベルの話だろう。

しかも「バカは放置」で切れるくらい小粒なバカだ。
放置しとけって
0159デフォルトの名無しさん2005/07/10(日) 06:16:27
>>157
インスタンス挿入ですか。
それ、AOPの話となんか関係あるの？
ついでに >>116, >>117との関連も説明してくれたらうれしい。
0160デフォルトの名無しさん2005/07/10(日) 06:17:28
>>157
それをDependency Injectionと呼ぶ村が、日本に存在するのですか？
0161デフォルトの名無しさん2005/07/10(日) 06:17:58
>>159
煽るなら、話の流れくらい読んでくださいよ。
0162デフォルトの名無しさん2005/07/10(日) 06:20:18
>>160 単なる生成パターンとDIの区別すら付かないなんて、相当山奥の村じゃないかな？
>>161 空気読めてないのはアンタ。DIとAOPの関連ですら不毛なのに。
0163デフォルトの名無しさん2005/07/10(日) 06:21:39
>>160
それがDIではないという話はきいたことがない。
0164デフォルトの名無しさん2005/07/10(日) 06:22:51
>>162
>>142-143から続いてるわけでしょ。
ねぇ、話の流れくらい、ちゃんと読める人になりましょうよ。
0165デフォルトの名無しさん2005/07/10(日) 06:23:51
じゃ放置の方向で。

>>116
「手続き」＋「データ」スタイルの逆襲か。悩ましいっすね。

akonさんのくーすblogに、
前Htpercardでなんか作ったら構造化分析設計に縮退しちゃったって話がのってた。
そして彼が言うには、DIコンテナの出現で、ステートレスななんか作ればばっちOKとかのたまってるんですけど。
いみふめ
0166デフォルトの名無しさん2005/07/10(日) 06:27:33
具体的な説明する能力がないから、放置なんだね。
0167デフォルトの名無しさん2005/07/10(日) 06:28:39
>>117
AOPを「〜できる魔法」とのたまっちゃうくらいだから、
きっと単なる意味なし宣伝文句か、
はたまたひがﾀﾝの理解の程がその程度なんだろ。

くーすみたいな話は、俺も去年取り組んでいたから、なんとなくわかる。
今年はもう業務アプリケーションから研究開発費用引き出す算段はやめにして、
もっとコアな話題をやるつもりだ。
0168デフォルトの名無しさん2005/07/10(日) 06:30:29
>>164
おまえはネットワーク浮浪者だろ。
きもいから寄るな。
ちなみに >>142は俺のレスだ。

AOPとDIの関係を議論したいなら、
あえてSeasarスレを汚しまくらずに、DIスレかAOP/アスペクト指向スレでヤレ。

以上
0169デフォルトの名無しさん2005/07/10(日) 06:32:24
>>168
DIに必ずしもインタフェースが必要ないといってるだけで、AOPとDIの関係の議論はしてないわけだが。
0170デフォルトの名無しさん2005/07/10(日) 06:32:46
>>164
だいたい早朝からいっぱいレス付いてるように見えるけど、
書き込んでるのはお前と俺の２名だけだって気づけよクズ
0171デフォルトの名無しさん2005/07/10(日) 06:34:02
>>169 じゃDIスレでヤレ。これ以上荒らすな。
0172デフォルトの名無しさん2005/07/10(日) 06:34:28
……………　き　り　と　り　せ　ん　……………
0173デフォルトの名無しさん2005/07/10(日) 06:35:50
>>170
もしかして>>158-160って、ひとりの書き込みなの？
そんなに必死だったの？
もうひとりいると思ってた。
0174デフォルトの名無しさん2005/07/10(日) 06:41:10
バカはどこまで逝ってもバカ。単に言い争いが大好きなだけの人格荒廃者。

さっさと氏ね
0175デフォルトの名無しさん2005/07/10(日) 06:42:26
今日は天気がいいな。
隣町まででかけて、カフェで仕事準備でもするか
0176デフォルトの名無しさん2005/07/10(日) 06:43:31
>>170
あれ？
じゃあ、>>160>>162ってジエンってこと？
ごめん、それに気づかないバカで。
そこまで必死だったなんて・・・
0177デフォルトの名無しさん2005/07/10(日) 06:52:14
>>117-118
広義の「制御の反転」 (IoC: Inversion of Control)は、
「ハリウッド原則」とも呼ばれていて、
EJBはじめオブジェクト指向の随所に散見されるが、

依存性注入 (DI: Dependency Injection)は、
もっと特化したスタイルの制御の反転であり、

最近、両者を混同する人が居る、つう話ね。
ようやく意図を理解した。
0178デフォルトの名無しさん2005/07/10(日) 06:58:52
>>157
http://martinfowler.com/articles/injection.html#FormsOfDependencyInjection
・Forms of Dependency Injection
　o Constructor Injection with PicoContainer
　o Setter Injection with Spring
　o Interface Injection

に載っている、Setter Injectionの話だな。
このあたりのありふれたテクニックになると、
もうDIとか特別な名前をつけてありがたがったりしないから、
これをDIと呼んでる人物が居る事をすっかり忘れてたよ。


■ このスレッドは過去ログ倉庫に格納されています