07/02/10 19:25:44
>>168
なるほどねぇ。
いやぁ、私もSpring使った開発に足つっこんじゃってて。
正直、使う前に予測してた弊害にモロにやられてるから。
ノウハウが足りないってのもあるけろ。
改めて思うのは、DI自体にそこまで価値あるのかしらっていう。
>>トレースログとか、トランザクション周りを排除できるだけでも使う価値はあるとおもう。
激しく同意だけど、これってAOP的要素なんだよね。
オブジェクトの疎結合によるメリットはまだイマイチ感じれないなぁ。
176:デフォルトの名無しさん
07/02/10 20:21:51
ただ導入すればメリットをえられると思っている単細胞には、ﾅﾆを使ってもメリットは得られないだろうねぇ
そういうヤツは何も考えずにゴリゴリ書いてガッツリ結合したプログラムを、またゴリゴリメンテナンスするのが
日常だから、考えてプログラム作ること自体がデメリットになっちゃうんだよね
そういう奴らが主導権を握ったプロジェクトだと、こっちまで巻き添えくうから困る
177:デフォルトの名無しさん
07/02/10 20:23:19
>>175
使う前に予測してた弊害って何？
178:デフォルトの名無しさん
07/02/10 20:38:13
疎結合そのものにメリット感じられないなら
DI使ったプロジェクトには来ないで欲しいよ・・
179:デフォルトの名無しさん
07/02/10 20:39:20
って言うか、オブジェクト指向言語使った開発全般に（ｒｙ
180:デフォルトの名無しさん
07/02/10 20:41:44
>>175
まずは依存関係逆転の原則でググれ。
181:デフォルトの名無しさん
07/02/10 20:43:54
>>175
>> 激しく同意だけど、これってAOP的要素なんだよね。
そうなんだよね。AOPを使ってトランザクション制御を書かなくていいんだ！ってのは理解してもらえるんだよ。
try,catch,finally close()とかはみんな煩わしいと思ってるし。
問題はDIの部分なんだよね。
setterインジェクションでDaoとか渡さなくても自分でnewすればいいじゃんてなる。
やれInterface書くのめんどくさくないの？とかsetter書くのがめんどいだのいうわけよ。
Daoなんか1個実装すれば終わりだし、ORMが途中で変わるわけないだろとか。
うちの人間は極端にリソースが増えるのを嫌がるからなぁｗ わからなくもないんだけどね。
182:デフォルトの名無しさん
07/02/10 20:45:07
Interface書くのがめんどくさいとかいうヤツは
コボルでもやってりゃいいんだよ
183:デフォルトの名無しさん
07/02/10 20:46:26
>>181
そういう奴らの方がよっぽどめんどくさい事を一生懸命やっているっていう事実を
当人達が気が付いていないのが笑える
184:デフォルトの名無しさん
07/02/10 20:46:53
>>181
自分でnewして良いかどうか、
JUnitでテストケースかいてみりゃ一発でわかるだろ。
185:デフォルトの名無しさん
07/02/10 20:53:15
PGレベルのやつはspring意識しなくて良いから「勉強ダルい」なんてことはないと思われ。
上でもあるが、トランザクションやログなど、アプリケーションの動作をプログラムから排除することで、
オブジェクト指向設計したメソッド呼び出しのみに注力することができるので見通しが良くなる。
186:デフォルトの名無しさん
07/02/10 21:07:56
蜜結合大好きならスクリプト言語の世界へどうぞ。
187:デフォルトの名無しさん
07/02/10 21:44:14
宣言的トランザクションを利用する場合も
TransactionManager, DataSourceなどをBean定義ファイルで設定してるよね？
あれってDIだよね？ｗ
これはkiddingだけど、
DIの価値がよくわからなければnewすることからはじめてもいいのでは？
それで問題がなければＯＫだし、その過程でDIの良さを理解できるかもしれないし。
一気にモジュールを作成してUnit Testをせずに
結合して単体テストするという文化ではnewでいけるのかも？
188:デフォルトの名無しさん
07/02/10 22:21:29
飲み過ぎだろ・・・常識的に考えてｗｗｗ
189:デフォルトの名無しさん
07/02/10 22:22:41
誤爆しましたｗ
190:デフォルトの名無しさん
07/02/10 23:37:41
あなたの常識って何ですか？東国原
191:デフォルトの名無しさん
07/02/10 23:53:40
＞DIの価値がよくわからなければnewすることからはじめてもいいのでは？
＞それで問題がなければＯＫだし、その過程でDIの良さを理解できるかもしれないし。
単に、問題の存在に気づかないだけだとおもう。
192:デフォルトの名無しさん
07/02/11 00:07:00
かもなｗ
193:デフォルトの名無しさん
07/02/11 00:08:26
>>191
問題って何？
194:デフォルトの名無しさん
07/02/11 00:20:52
理解力不足と、そう思われるのがイヤで
難癖付けるヤツ
195:デフォルトの名無しさん
07/02/11 00:22:42
自分自身のこと？ｗ
196:デフォルトの名無しさん
07/02/11 00:26:03
あと、空気読めないガキ
197:デフォルトの名無しさん
07/02/11 00:26:37
なんか現状に不満みたいだねｗ
198:デフォルトの名無しさん
07/02/11 01:54:09
>>191-197
これがSpringを導入するかしないかで繰り広げられる会話か。
199:166
07/02/11 02:53:16
うあ。大反響だ。
この中で実際開発してる人っているんですよね。
理想論は理解できるけど、どれだけ『体現』してるのかな。
それも個人ではなくプロジェクトとしてね。
ISID内じゃ前からSeasar2不評だよ。
タ ブ ー だ け ど 。
200:デフォルトの名無しさん
07/02/11 03:03:48
>>199
どうでもいいけど、>>175で書いてた、使う前に予測してた弊害って何よ？ｗｗｗ
201:デフォルトの名無しさん
07/02/11 03:04:13
疎結合否定した時点で、真性かネタの二択だよ俺的には。
202:デフォルトの名無しさん
07/02/11 03:05:27
今時DIすらわからんJava開発者は、さっさとRubyあたりに移った方が身のためだと思う
多分Rubyもわからなくて廃業するだろうけどな
203:デフォルトの名無しさん
07/02/11 04:05:38
実際、楽になったといえるような香具師はいないだろうねぇ
Strutsがそうであるように、結局使いこなせなくて大変な思いだけ
が記憶に残ってしまうんだよね
とSpring使ったことないオレがイって見る
204:デフォルトの名無しさん
07/02/11 04:30:32
だからさっさとスクリプト言語でも何でも、簡単な方にいけばいいのに
DI以前のクソソースしか書けないJava開発者が、現場では一番使えない
205:デフォルトの名無しさん
07/02/11 05:27:13
ｸﾝｸﾝ
ﾑﾑｯ！！
ｺ・・・ｺﾚﾊ！！！
206:デフォルトの名無しさん
07/02/11 08:49:34
>>203
とことん楽になったよ。
あとStrutsと比較したらただのアホだから、
人前では決して口にしないように。
DIは(AOPも)パラダイムなんだから。
構造化言語、オブジェクト指向、とかと同列。
進化の方向は「関心ごとを極小にして実装に集中する」で一致してる。
207:デフォルトの名無しさん
07/02/11 10:41:51
>>203
Javaも使いこなせてないみたいだな
208:デフォルトの名無しさん
07/02/11 10:44:20
>>204
人の上に立てないやつ
209:デフォルトの名無しさん
07/02/11 10:47:07
>>199
>ISID内じゃ前からSeasar2不評だよ。
これほんと？(ぁゃιぃ)
不評な理由はなに？
210:デフォルトの名無しさん
07/02/11 11:01:34
なんかさ、
ジャヴァ・スプリング・フレームワーク と
ネギ・スプリング・フィールド って
なんかにてね？
211:デフォルトの名無しさん
07/02/11 11:03:50
ネギ・スプリング・フィールドはおまえにそっくりだな
212:デフォルトの名無しさん
07/02/11 11:59:28
なんか暖冬のせいか、馬鹿がたくさん沸いてでてきてるな
213:デフォルトの名無しさん
07/02/11 12:00:39
>>206-207
そういう意味で比較したんじゃないからｗ
日本語も読めないようなヤツだと大して使いこなせてもいないんだろう
214:デフォルトの名無しさん
07/02/11 12:16:30
必死だなｗｗｗ
215:デフォルトの名無しさん
07/02/11 12:43:38
ネタだと思いたい。
216:デフォルトの名無しさん
07/02/11 12:44:51
>>212
そりゃ、春のフレームワークだからなｗ。 Spring = 春
217:デフォルトの名無しさん
07/02/11 12:53:49
バネもってこい！
218:デフォルトの名無しさん
07/02/11 12:59:28
温泉のフレームワークじゃないの？
219:デフォルトの名無しさん
07/02/11 13:28:49
スプリングフィールドとかって名前の外人さんいそうじゃねｗｗｗ
220:デフォルトの名無しさん
07/02/11 13:34:40
DIの考え方は肯定するがDIの存在は否定するよ。
DI使いこなせるやつは密結合でもちゃっちゃと作れる。
DI理解できないやつは密結合の方が早かったりする。
現実問題として多数の人間が後者なんだよ。
この状況でDIコンテナ導入するのは最適かね。
私が言っていた弊害てそういうこと。
ムキになって噛みついてきてる方々は、普段からあまりDIの良さをわかってもらえず、もどかしい思いをしているのかな。
残念ながら多くのプログラマは君達よりずっと馬鹿。
有識者やセンスある人の内輪で盛り上がり、気付いたらJavaの市場規模は縮小してました なんて平気でおきそうで。
『誰にでも』簡単に、より速く これが理想でしょ。
まあ上位開発者がフレームワークでDIを完全に隠蔽できればどーにかなるんらけろ
221:デフォルトの名無しさん
07/02/11 13:42:17
>>220
作業の分担の仕方を変えれば、あっさりうまくいくよ。
旧来式：
・うまい奴が難しい業務
・下手な奴が簡単な業務
DI導入後：
・うまい奴が全業務のインタフェースを切る
・下手な奴はインタフェースを実装する
222:デフォルトの名無しさん
07/02/11 13:55:20
>>221
そのうまい奴がいないでDI導入するプロジェクトが存在する訳だが・・・
223:デフォルトの名無しさん
07/02/11 13:58:16
>>222
それは流石に無謀だろｗ
224:デフォルトの名無しさん
07/02/11 14:08:48
うまい奴がいないプロジェクトはDI導入しようがしまいがこけるでしょｗ
225:デフォルトの名無しさん
07/02/11 14:10:14
自分はわかっていると思っているヤツがいるプロジェクトが一番危ういｗ
226:デフォルトの名無しさん
07/02/11 14:11:41
DIxAOPの宣言的トランザクションや他フレームワークとの連携機能は使いたいが、
DIのメリットが享受できない、理解できない場合は蜜結合すりゃいいんだよ。
227:デフォルトの名無しさん
07/02/11 14:12:16
220は導入主導したやつにうまい奴だと期待されたんだな。
お前は何も悪くない。そいつの目が節穴だっただけだ。
＞上位開発者がフレームワークでDIを完全に隠蔽できればどーにかなるんらけろ
こんなのは当たり前にやってることなんだよ、普通なら。
228:デフォルトの名無しさん
07/02/11 14:15:42
>>225
他の奴がわからないと、調べろよとか、
そんな馬鹿な奴らと仕事したくないとか、
俺が５人いたらなとか言う奴がアーキテクチャーを
仕切っていると確かにやばいなｗ
そういう奴は自己中でプロジェクトの成功だとかコストといった観点が抜けてる。
229:デフォルトの名無しさん
07/02/11 14:21:33
>>222だが、
DI導入を推進してすんごいインターフェースきりまくった奴が逃げ出した
残骸見る限り使い方もわかってない様子。
230:デフォルトの名無しさん
07/02/11 14:22:15
>>228
＞他の奴がわからないと、調べろよとか、
＞そんな馬鹿な奴らと仕事したくないとか、
むしろDIコンテナは、雑魚に何らの調査力を期待しないで済むように
デザインされていると感じるが。
231:デフォルトの名無しさん
07/02/11 14:24:00
>>229
何がいいたいかわかんね
232:デフォルトの名無しさん
07/02/11 14:24:47
DIコンテナといったコンテキストの話じゃない
233:デフォルトの名無しさん
07/02/11 14:27:27
>>229
それはDIうんぬんの問題というよりも
そいつが技術的に仕切れる奴じゃなかったという話では？
234:デフォルトの名無しさん
07/02/11 14:33:18
そういう話
235:デフォルトの名無しさん
07/02/11 14:47:11
よし、今からDIとやらをやるぞ。
ところでJavaもプログラム言語も
ほぼ素人の新人なのだが、
勉強すべき用語をリストアップしてくれ！
236:デフォルトの名無しさん
07/02/11 14:51:10
>>235
1. 単一責任の原則（SRP：Single Responsibility Principle） クラスを変更する理由は1つ以上存在してはならない
2. オープン・クローズドの原則（OCP：Open-Closed Principle） ソフトウェアの構成要素（クラス、モジュール、関数など）は拡張に対して開いていなければならず（オープン：Open）、修正に対しては閉じていなければならない（クローズド：Closed）
3. リスコフの置換原則（LSP：Liskov Substituion Principle） 派生型はその基本型と置換可能でなければならない
4. 依存関係逆転の原則（DIP：Dependency Inversion Principle） a. 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきであるb. 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである
5. インターフェイス分離の原則（ISP：Interface Segregation Principle） クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない
237:デフォルトの名無しさん
07/02/11 14:53:55
>>235
仕事ならマジ勘弁してくれ
238:デフォルトの名無しさん
07/02/11 14:54:07
SRP、OCP、LSP、DIP、ISP だな？
他に知っておく技術は無いか？
俺は素人だからな。当然基礎的なものから全部だ
239:デフォルトの名無しさん
07/02/11 14:54:46
「人」についての理解が重要です。
240:デフォルトの名無しさん
07/02/11 14:55:42
>>238
それらを習得する過程で必要なものは全て手に入る。心配するな。
241:デフォルトの名無しさん
07/02/11 14:56:38
>>240
その必要なものをすべてリストアップしてくれ！
242:デフォルトの名無しさん
07/02/11 15:05:25
>必要なもの
他の業界への転職
243:デフォルトの名無しさん
07/02/11 15:06:15
明らかにスレ違いだと分って聞きます。すみません。
Spring Frameworkのような仕組みで、
デスクトップアプリを作ろうと思えば
なにを使えばいいのでしょう？
最近のフレームワークは
WebアプリでHTMLやHTMLっぽいテンプレートを
使ってUIを実装する話しばかりで困ります。
244:デフォルトの名無しさん
07/02/11 15:08:23
Spring Frameworkのような仕組み とは？
245:デフォルトの名無しさん
07/02/11 15:10:04
>>243
日本語でおｋ
246:デフォルトの名無しさん
07/02/11 15:14:43
>>244
えぇ、ですからいわゆるウインドウで作りたいのです。
Windows Formsとか、GTKとかQTとか。
247:デフォルトの名無しさん
07/02/11 15:17:15
お前はSpringをなんだと思ってるんだ？
248:デフォルトの名無しさん
07/02/11 15:19:34
もう一度聞く
Spring Frameworkのような仕組み とは？
249:デフォルトの名無しさん
07/02/11 15:21:23
>>243
電子レンジのような仕組みで、
デスクトップアプリを作ろうと思えば
なにを使えばいいのでしょう？
と質問されたら貴方はどう答えますか？
250:デフォルトの名無しさん
07/02/11 15:25:32
Springはよく知らないが
SpringでSwingコンポーネントを構成して、部品をFrameにDIさせて実行すればいいんじゃね？
JFrameが部品だらけでごちゃごちゃになるのは
DIコンテナを使えばある程度綺麗にまとめられる気がする
NetBeansやVEが対応できなさそうだが
251:デフォルトの名無しさん
07/02/11 15:31:54
>>250
NetBeans使った場合コンポーネントのプロパティがDIの定義だと考えるんだ
実際のところインターフェースベースは使い物にならないし複雑にイベントが飛び交うので無理
252:デフォルトの名無しさん
07/02/11 15:37:46
無理？
253:デフォルトの名無しさん
07/02/11 15:41:17
>>251
Component自体が継承前提だし、実装に依存した細かなプロパティを外側から変更したいしで
よく考えれば、たしかにインターフェイスベースは無理がありそうだな
DIでの開発に慣れた後にSwingのソースを読むと、ごちゃごちゃしすぎて嫌になるが
あれはRADで開発するものだと割り切るべきか
254:デフォルトの名無しさん
07/02/11 15:51:03
GUIコンポーネントはプロパティが動的に変わるものだから使えないな
DIってあらかじめ挙動がわかっていて成り立つもの
ただ、GUIコンポーネント単位で使うのではなく、それらを包括した単位で扱うのなら可能
その場合フレーム単位で扱うことになるだろうね
結局はコンポーネントを制御する部分が一番厄介なところなので恩恵はあまりないけど
あとでまるごと作り直したフレームと交換とか出来るようになるのはいいのかもしれない
それでも結局サービスロケータの域からはでないな
おそらくゲームのほうが適用範囲は広いかと
255:220
07/02/11 15:53:50
しーましぇん、ちなみに私は>>166です。
ちなみに>>227 私は開発に加担してるけどコーディングも設計もしてないお。
>>221の言うとおりの役割分担になるんだろうね。
ただ、プロジェクトによって(人員の)質のバラつきがあるからねｗ
>>222の言うような状況は発生するんだな。
上位開発者が上手に作れば>>230の言うことおりってのもわかる。
少数の優秀なプログラマと多数の雑魚でチームが構成されても、そこそこイケそう。
>>雑魚に調査力を期待しないで済む
これねえ。 この状態に持っていけるような技術者以外DIに絡むなってことか。
私には扱えないね。
デューダするかな。
256:デフォルトの名無しさん
07/02/11 16:07:27
>>254
以前作った奴だと getBean 呼びまくりになって
DIでもなんでもなくなっちまったですよ。
そのアプリに適した画面フレームワークを作成した方が
最終的なコストは低く抑えられるし、
変更にもむしろ強いだろうってのがその時得た感触。
画面はやっぱ面倒ですね。
何が面倒って、お客・利用者の目にモロに触れるから
要求の変更速度がやんごとないところ。
257:デフォルトの名無しさん
07/02/11 16:08:25
256はあくまでも画面(ビュー)の話ね。
258:デフォルトの名無しさん
07/02/11 16:18:48
つまりある程度以上の複雑さのものまでしか扱えないってこと？
259:デフォルトの名無しさん
07/02/11 16:19:23
日本語変だなｗ
扱える複雑さに上限があるってこと？
260:デフォルトの名無しさん
07/02/11 16:20:37
どのような物にも・・・(ry
261:デフォルトの名無しさん
07/02/11 16:22:26
つーか・・・C#が無料なのに？DI使いたければS2.netとかもあるのに？デスクトップアプリでjava？
262:デフォルトの名無しさん
07/02/11 16:26:00
LinuxやMacでも動かさないとならないのです
263:デフォルトの名無しさん
07/02/11 16:27:48
あっそ
264:デフォルトの名無しさん
07/02/11 16:29:43
リッチクライアントの最先端に興味がある奴は あぱれっと様のご意見を参考にしろ。
URLﾘﾝｸ(www.atmarkit.co.jp)
265:デフォルトの名無しさん
07/02/11 16:33:30
>>264
吹いたｗｗｗ
266:デフォルトの名無しさん
07/02/11 16:34:01
>>256
お偉いさん相手にすると見た目大事なんだよな
帳票も5mこっちにずらせとかすごい多い
WEBアプリだと多少見た目や操作性が貧弱でもいいけど、
リッチなクライアントだとほんと細かい制御をさせられるから無理
JavaSEにJAX-WSとグループレイアウトが標準搭載されたことでたぶんリッチクライアントははやると見てる
鯖もEJB3はDIコンテナになったし、どのDIプロダクトを使おうがDIは必須の知識にはなるだろうね
そしてそのPOJOで作られたEJB3コンポーネントをJAX-WSですぐに公開が可能
1年前のEJB2.1までとは別次元の開発効率になったな
267:デフォルトの名無しさん
07/02/11 16:36:52
１年前のPOJOでの開発と比べてはどう？
268:デフォルトの名無しさん
07/02/11 16:36:53
Springは細かい仕様変更要求に弱いってこと？
5mだったらこまかくないか
269:デフォルトの名無しさん
07/02/11 16:38:35
>>261
クライアントがWindowsだけならC#でもいいかもしれんけど、Javaのクライアントはかなり作りやすいよ
C#はDelphi時代の古いものという感じが強い
当時はBCBともどもお世話になったけど
C#だって無料なのはへぼい開発環境なやつだけなのは問題
クライアントと鯖とで技術者を2つの言語を扱える人を探すより1つの言語を扱える人を探すほうが楽だしな
>>264
一般人には考えもつかないような斬新なシステム・・・
それにしてもリッチクライアントでのJavaクライアントが多いね
1年前というJAX-RPCが使いにくい時代の割には・・・
270:デフォルトの名無しさん
07/02/11 16:39:42
>5mだったらこまかくないか
ﾜﾛﾀｗ
271:デフォルトの名無しさん
07/02/11 16:41:21
>それにしてもリッチクライアントでのJavaクライアントが多いね
Javaのフォーラムですからｗｗｗ
272:デフォルトの名無しさん
07/02/11 16:47:18
>>267
Spring1.2だったかな
それで開発してたけど結局設定ファイルを書くのが面倒だとか
ビジネスロジックに直接絡まないセッターのコードが邪魔とかいろいろいわれて
なかなかDIは認識してもらえなかったよ
柔軟性のあるサービスロケータとしてしか使ってない感じかな
EJB3でテストプロジェクト動かしてるけど、これだとフィールドインジェクションであることやXML必要としないことで
すんなり使ってもらえてる
プライベートな変数にインジェクションしてくれるのはわかりやすくていいね
Spring2は扱ってないのでなんともいえない
フィールドインジェクション使いたかったらSeasar2＋EJB3アノテーションを使って勉強という手もあるね
273:デフォルトの名無しさん
07/02/11 16:56:26
ほうほう。
俺たちはこれからSpringとEJB3にどう付き合っていけばいいの？
・分散とかSFSBとかを使う必要がある場合はEJB3を使うが、EJB3の機能が特に不要な場合はどちらでもいい？
・EJB3が今後開発の標準になっていく？
・Java Webアプリの大多数はEJB3コンテナを必要としないので、EJB3はあまり普及しない？
・SpringはEJB3とうまく連携していく？
・その他？
識者の方、ご意見よろぴこ
274:デフォルトの名無しさん
07/02/11 16:59:12
Javaは業界全体で迷走中
HibernateがEJBに逆流したあたりから顕著になってきた
275:デフォルトの名無しさん
07/02/11 16:59:36
>>254
>DIってあらかじめ挙動がわかっていて成り立つもの
↑これ本当？
276:デフォルトの名無しさん
07/02/11 17:01:18
ある意味本当でもあるし、ある意味違うとも言える。
>>275
どのようなケースを考えてる？
277:デフォルトの名無しさん
07/02/11 17:07:53
>>272
Spring Annotationという手は？
278:デフォルトの名無しさん
07/02/11 17:12:39
>>276
いや具体的にどうって言うわけじゃないんですけどね。
はっきり言い切ってるから気になったんさ。
279:デフォルトの名無しさん
07/02/11 17:24:58
>>274
HibernateがEntityBeanを乗っ取ったという方が近い
280:デフォルトの名無しさん
07/02/11 17:32:34
>>279
Hibernate微妙じゃない？
HQL廃止すれば、少しは光さすけど。
281:デフォルトの名無しさん
07/02/11 17:37:06
スレ違いだ スマン。
282:デフォルトの名無しさん
07/02/11 17:50:24
>>269
>C#はDelphi時代の古いものという感じが強い
>それにしてもリッチクライアントでのJavaクライアントが多いね
>C#だって無料なのはへぼい開発環境なやつだけなのは問題
>クライアントと鯖とで技術者を2つの言語を扱える人を探すより1つの言語を扱える人を探すほうが楽だしな
色々とすごいな・・・
283:デフォルトの名無しさん
07/02/11 17:56:49
EJB3のコア技術の一つJPAはまず普及する技術だろうね
DBマガジンだっけ？アレでちょうど特集やってるね
HibernateはHibernateEMということでJPAの実装のひとつと思うくらいがちょうどいい
実装はどれもオープンソースだし一長一短だと思うがリファレンス実装になってるTopLinkはわりと素直でいい動きしてる
TopLinkは新人に見えるが歴史は長くJavaが登場する前からあるのも面白い
Java版のTopLinkも登場してから8年くらいたってるんだっけ
まぁリファレンス実装というのがどれだけ強みなのかはTomcatを見れば明らか
そして今JavaEEのリファレンスという位置づけでオープンソースなglassfishが稼働中
glassfishはJavaEE鯖の中では軽量なほうで5秒あればノートでも起動するね
Tomcatで面倒なコネクションプールを定義するくらいならglassfishでやったほうが手っ取り早い
EJB3の利点はJavaEEのコアな技術ということでフリーから商用のさまざまな鯖で動かせるというのがいい
JavaEEが注目されはじめたのはその技術そのものよりオープンソースのAP鯖など環境面での影響があると思う
今までサーブレット/JSPしか注目されなかったけど、Tomcatもフリーでテストする環境がすぐに用意できたという理由はあると思う
284:デフォルトの名無しさん
07/02/11 18:01:39
>>277
コード見たことないのでわからんけど
フィールドインジェクションしてくれるならいいと思う
ただ、Springのプロジェクトって全体的にhibernateにべったりなのがちと気になる
Seasar2もJPA無視なんだっけ？
285:デフォルトの名無しさん
07/02/11 18:17:54
>>259
上限があるのは複雑さじゃなくて、変化の度合い。
画面アプリは朝令暮改の仕様変更なんてザラ。
サービス仕様決めて・・・とかが水泡に帰す。
この場合、何使って作ってもグダグダになるので
逃走の準備をきちんとしとくのが何よりも大事。
286:デフォルトの名無しさん
07/02/11 18:25:19
>>266,283
きしだﾀｿ乙
287:デフォルトの名無しさん
07/02/11 18:56:05
>まぁリファレンス実装というのがどれだけ強みなのかはTomcatを見れば明らか
実例はTomcatだけ？ｗ
JPAがTopLinkよりもHibernateの仕様にかなり近いことを考えると、
Hibernate EMの方が良いのではという考えもあるのでは？ｗ
JPA実装を何するかは様々な観点から検討する必要があり、
プロジェクトによっても採用基準が異なるだろうから
単純に年数だけで決定すると失敗するかも。
288:デフォルトの名無しさん
07/02/11 19:04:23
>>266は岸田たんというよりもたぶん >>3だろｗｗｗ
289:デフォルトの名無しさん
07/02/11 19:11:59
>>284
フィールドインジェクションはしてくれなかったと思う。
>ただ、Springのプロジェクトって全体的に
>hibernateにべったりなのがちと気になる
この感覚は俺にはわからない。
>Seasar2もJPA無視なんだっけ？
Seasar2はJPAをサポートしてるよ。
S2Hibernate-JPA, S2TopLink-JPA, Kuina-Dao。
Kuina-Daoは動的な問い合わせを生成したりするのにかな～り便利。
まだ品質は今一歩かもしれないけどｗ
290:デフォルトの名無しさん
07/02/11 19:17:07
Session Beanの単体テストって簡単にできるの？
俺、昔のEJBの印象が残っててそこが引っ掛かるんだけど。
291:デフォルトの名無しさん
07/02/11 19:23:53
>>290
昔のEJBと同程度のユニットテストしかできないと思っていた方がいい。
過剰な期待は禁物。
つまり、ビジネスメソッドの正常系のみ。
トランザクションやセキュリティロールが絡むとダメダメ。
292:デフォルトの名無しさん
07/02/11 19:23:53
>>288
グループレイアウトやJAX-WSごときでJavaクライアントがはやるなんて
寝言がいえるのはきしだﾀｿしかいない
よって>3もきしだﾀｿ
293:デフォルトの名無しさん
07/02/11 19:24:05
POJOですからｗｗｗ
294:デフォルトの名無しさん
07/02/11 19:24:42
＞よって>3もきしだﾀｿ
なら納得ｗｗｗ
295:デフォルトの名無しさん
07/02/11 19:26:58
>>290
EJBは
Context c = new InitialContext();
(NewInterface) c.lookup("NewInterface");
見たいな感じで取得すればおけ
getBeanとやれることはかわらん
296:デフォルトの名無しさん
07/02/11 19:27:19
>>291
経験に基づいたコメントサンクス
>過剰な期待は禁物。
そっか。
俺はしばらくは Struts + Spring + JPA/iBATIS でいいやｗ
297:デフォルトの名無しさん
07/02/11 19:41:23
>>291
具体的にたのむ。
298:デフォルトの名無しさん
07/02/11 19:43:43
釣れてきましたね～ｗｗｗ
299:デフォルトの名無しさん
07/02/12 02:01:58
>>243
あなたはSpring FrameworkがWebアプリ専用だと思ってますね？
他の人が答えたようにSpring Framework上でSwingアプリを作れます。
Javaでスクラッチ開発より楽にデスクトップアプリを作りたいのなら
スタンドアローンアプリでなくEclipseかNetBeansのプラグインを作れば
典型的処理をFrameworkにまかせてアプリ固有処理に専念できます。
「統合開発環境Eclipseプラグイン開発QA」
ｽﾚﾘﾝｸ(tech板)
WebアプリでHTMLなどでUIを実装するようにデスクトップのUIを実装したい、
という話だったらSynthをどうぞ。
「進歩したSynth」
URLﾘﾝｸ(www-06.ibm.com)
300:デフォルトの名無しさん
07/02/12 02:04:45
そういえばSpring RCPとかあったな。
URLﾘﾝｸ(spring-rich-c.sourceforge.net)
301:デフォルトの名無しさん
07/02/12 02:25:19
swingったってviewが変わっただけだと思うんだが。
302:デフォルトの名無しさん
07/02/12 07:41:59
Swing Application Frameworkってあったな。内容は知らないけど
あれがSwingのView部分を受け持って、ロジック側をSpringが受け持つようになれば
Struts+Springみたいなイメージで使えるようになるだろうか
303:デフォルトの名無しさん
07/02/12 10:31:44
上の方でGUIは無理ぽって言ってるひとがいるじゃん。
304:デフォルトの名無しさん
07/02/12 10:57:44
>>303
そのうちの一人が俺ｗ
305:デフォルトの名無しさん
07/02/12 11:33:01
>>303-304
Ｖｉｅｗと密結合でつか？ｗ
306:デフォルトの名無しさん
07/02/12 11:56:40
View内で完結される話で、ロジック以下を密結合させるわけではない。
Viewから上のレイヤはレイヤ内でよろしくやれってことだ。
307:デフォルトの名無しさん
07/02/12 12:40:04
>Viewから上のレイヤは
サービス層などは上か下かと言えばViewの下のレイヤようなｗ
「Viewから先のレイヤ」の方がまだしっくりくる
308:デフォルトの名無しさん
07/02/12 12:43:06
っていうか、Ｖｉｅｗ内でよろしくならそのＶｉｅｗがＧＵＩだろうがＣＵＩだろうが
ＪＳＰだろうがなんだっていいんじゃねーの？ｗ
309:デフォルトの名無しさん
07/02/12 12:56:25
>>305
View部分には使えない。
それ以外に使おうとするとメリットが少ない。というかほとんどない。
310:デフォルトの名無しさん
07/02/12 13:02:24
>>309
Sptingは、WebアプリのViewを実装する事にしかメリットが得られる使い道が無い
といっている？
311:デフォルトの名無しさん
07/02/12 13:03:27
>>310
ゴメン、間違えたｗ
312:デフォルトの名無しさん
07/02/12 13:09:49
だれもViewでSpringを使いたいという話はしていない件
313:デフォルトの名無しさん
07/02/12 13:10:30
>>310
309ではないが、そんなことは言ってないと思うし、
SpringはWebアプリのViewの実装をサポートするだけではないのは明らか。
314:デフォルトの名無しさん
07/02/12 13:17:39
>>310だけど、>>309を読み間違えましたｗ
「View部分には・・・」と「それ以外・・・」という言葉のつながりが
よくわからん買った
315:デフォルトの名無しさん
07/02/12 13:45:44
この流れ見ててわかるだろ。
無理してSpring使うなｗ
316:デフォルトの名無しさん
07/02/12 13:53:43
>>308
なんだっていいだろ。
何かに限定する話なんぞ誰もしていない。
317:デフォルトの名無しさん
07/02/12 13:57:01
なんでもいいよ
なんにしても大した発言は無いスレだｗ
318:デフォルトの名無しさん
07/02/12 13:59:03
>>317
これこれｗ
だが、「こないだ雑誌にのってたのマンマだな」とかよくあるｗ
319:デフォルトの名無しさん
07/02/12 13:59:21
>>317様
是非仕事に役立つSpringのTipsをご紹介下さい
320:デフォルトの名無しさん
07/02/12 14:00:36
上の方でもDB MagazineのJPA特集読んで知ったかしてた馬鹿がいたなｗ
321:デフォルトの名無しさん
07/02/13 00:29:56
あー、Ｗｅｂ層のフレームワークって何がいいのでしょうか？
お馬鹿な私にはStrutsは難しいです・・・
322:デフォルトの名無しさん
07/02/13 00:36:30
SpringMVC
323:デフォルトの名無しさん
07/02/13 00:40:07
SpringMVCですか・・・
Strutsとあまりかわらないような・・・
そんなことないですか？
324:デフォルトの名無しさん
07/02/13 00:45:50
自作が一番わかりやすいよｗ
325:デフォルトの名無しさん
07/02/13 00:48:55
サンプル見ただけなんですけど、
Clickってわかりやすそうに感じました。
１人プロジェクトならいいんでしょうけどね（苦笑）
326:デフォルトの名無しさん
07/02/13 00:52:02
Springスレなんであれだけど、
もうちょっとしたらSeasarのTeedaがおもしろいと思うよ。
327:デフォルトの名無しさん
07/02/13 01:42:30
SpringMVC (ViweはVelocityが良いと思われ。)
Wicket
Teeda
この辺りが有力株か？
簡単なものは SpringMVC+Velocity でやっつけて
ある程度面倒になったら WebService+RichClient で
ってのが最近の俺のパターン。
328:デフォルトの名無しさん
07/02/13 03:09:24
SpringMVCって戻るボタン、ダブルクリック、マルチウィンドウ対策とかしてくれる？
329:デフォルトの名無しさん
07/02/13 06:59:00
JBoss Seamがいい。
330:デフォルトの名無しさん
07/02/13 09:55:39
>>328
WizardFormController使ったアプリで、
マルチウィンドウ試したら思いっきりデータが上書きされたorz
やり方悪い！？
331:デフォルトの名無しさん
07/02/13 10:38:37
>>328
個人的にはMVCでそんなもんコントロールするなよって思う。
レイヤがそもそも違うじゃねえかと。Viewで勝手にやったらいい。
下位レイヤでサービスしようとするといつか破綻する。
そこまでしてWebアプリにするなってのが本音。
332:デフォルトの名無しさん
07/02/13 11:13:15
>>329-331
コメントとんくす
やっぱりSpringMVC単体で解決してはくれないのねん。
こういった制御コードはもう書きたくないし、
そうなるとTeeda, Seamを選択したくなっちゃうのよねん。
333:デフォルトの名無しさん
07/02/13 11:21:25
>>331
気持ちはわからないでもないが、
何の解決策にもならない。
334:デフォルトの名無しさん
07/02/13 13:09:41
Strutsみたいにトークンの管理をWebフレームワークにさせたいと思うのは自然じゃないか？
が、コードに決まりきったこと書くのはメンドイ。設定ファイルだけでできるとうれしいな。
というかこういうのをAOPで何とかできないのかね？
で、それ以上のこと(ボタンを押せないようにしたいとか)はView(のJavaScript)でやればいいとｵﾓﾀ。
なんか的外れ？
335:デフォルトの名無しさん
07/02/13 13:12:13
>>334
的外れじゃないと思うよ。
その解決策の１つがJBoss Seamだって話。
336:デフォルトの名無しさん
07/02/13 13:16:52
>>335
Teedaも忘れないでね (。-_-。)ポッ
337:デフォルトの名無しさん
07/02/13 13:17:46
おー、そーりー、そーりー
Teeda最高！
Seasar最高！！！
これでよい？ｗ
338:334
07/02/13 13:21:21
>>335
そうなのか。Seamって使ったことないからわからなかった。
ﾄﾝｸｽ。
>>336
URLﾘﾝｸ(www.seasar.org)
これ？
でもスレ違いじゃないかぁ？！ｗ
339:デフォルトの名無しさん
07/02/13 13:38:13
>>338
Seamもスレ違いな件
340:デフォルトの名無しさん
07/02/13 13:46:07
選択肢提示するだけならまぁいいんじゃねえの？
Springの話をここでしかしないわけでもないんだし。
詳細に立ち入るならスレ違いだが。
341:デフォルトの名無しさん
07/02/13 13:52:07
>>339
全くすれ違いというわけではないと思うよ。
だって、Seam使う人はSpringを同時に使うことはたいていないわけで、
「じゃあSpringを使って開発していてSeamと同様の機能を
享受するにはどうしたらいいの？」
っていう話に発展してくれること願って投稿したんだけどねｗ
念のため言っておくけど、HibernateとiBatis、StrutsとJSFのように
SpringとSeamは同列のものだとは思ってないよ。
342:デフォルトの名無しさん
07/02/13 14:02:31
>>341
SeasarのTeedaでは一部Seamを意識しているところがあるよね？
Spring使って開発している場合、
自前で制御コード書いてやってるケースがほとんどじゃない？
Ｗｅｂ特有の問題について全く考慮していない
Ｗｅｂアプリも少なくないと思う。
343:デフォルトの名無しさん
07/02/13 14:09:14
>SeasarのTeedaでは一部Seamを意識しているところがあるよね？
これは俺も感じたｗ
>Spring使って開発している場合、
>自前で制御コード書いてやってるケースがほとんどじゃない？
Springの責任というわけではないというのはいいよね？ｗ
Struts で開発している人ってSpringを導入しても
たいへんなんじゃないかな？
もう体にしみついちゃって不感症状態なのかもしれないけどｗ
344:デフォルトの名無しさん
07/02/13 14:35:44
Struts開発で業務に集中したい場合は、Valentine Frameworkがいいかも
URLﾘﾝｸ(www.valentineframework.org)
345:デフォルトの名無しさん
07/02/13 14:41:07
あれ、バレンタインのつづり違う？
346:デフォルトの名無しさん
07/02/13 15:22:30
SpringMVC自体はあくまでもMVCで
ViewはViewでよろしくやりやがれってスタンスでは？
(Controllerが抽象化されたModelAndViewを返してくるだけ)
347:デフォルトの名無しさん
07/02/13 16:35:35
>>346
それはそれでいいんだけど、
現実問題としてＷｅｂ固有の問題は解決しないといけないよね？
それはViewで解決する問題っていってる？
その場合のViewって具体的に何？
348:デフォルトの名無しさん
07/02/13 16:41:25
Spring2.0入門買いました
すごいいいとおもいました
349:デフォルトの名無しさん
07/02/13 16:44:19
おれもかったよ
著者は印税がっぽがっぽじゃね？
350:デフォルトの名無しさん
07/02/13 16:45:53
>>330
ﾜﾛﾀｗｗｗ
ｵﾚもそうなったｗｗｗ
351:デフォルトの名無しさん
07/02/14 00:16:43
>>348-349
俺もかおっかなー・・・・
352:デフォルトの名無しさん
07/02/14 00:39:06
みんなで買って、はせがわさんをスプリング長者にしてあげよう♪
353:デフォルトの名無しさん
07/02/14 13:03:54
Spring2.0入門Amazonで買ったけど、
Springわかってない俺にはSprng入門が必要だった orz
354:デフォルトの名無しさん
07/02/14 13:57:09
そこで Reference Manual ですよ。
ていうかこれ日本語化してるプロジェクトとかある？
周囲に日本語になってないと読まないやつが多数居て泣ける。
355:デフォルトの名無しさん
07/02/14 14:28:37
>>354
URLﾘﾝｸ(andore.com)
356:デフォルトの名無しさん
07/02/14 17:57:34
>>354
Reference Manual読むのがつらいかたら買ったのに？ｗ
最初はつらかったけど、Spring2.0読んでいくうちにたいぶわかってきた。
なんとかJPAを使ったDao作成までできるようになった。
357:デフォルトの名無しさん
07/02/15 00:57:59
便利だねコレ
358:デフォルトの名無しさん
07/02/15 09:09:37
今日はでぶさみいきまつよ
JSUGのみなたまよろしくでつ
359:デフォルトの名無しさん
07/02/15 22:16:32
コアパッケージ含め、全てのnewをSpring経由にしてみたんだけど・・・
完全にプロジェクト失敗だ。
360:デフォルトの名無しさん
07/02/15 22:28:23
>>359
明らかにおかしい
間違いなくプロジェクトがこけたのはお前のせい
361:デフォルトの名無しさん
07/02/15 22:41:54
StringBuffer とか BigDecimal とかも全部ってことか
362:デフォルトの名無しさん
07/02/15 23:21:24
中庸と言う言葉があってだな
363:デフォルトの名無しさん
07/02/15 23:47:23
使える奴には良い道具を与えよ。
使えない奴にはｒｙ
364:デフォルトの名無しさん
07/02/15 23:51:38
>>359のような馬鹿はすっこんでろ！
お前は定型作業やってりゃいいんだよ
回りを不幸にするな
365:デフォルトの名無しさん
07/02/16 00:21:42
newを全部って、楽しいヤツだな
366:デフォルトの名無しさん
07/02/16 01:51:36
Stringとかどうやったんだろう。
367:デフォルトの名無しさん
07/02/16 23:58:57
>>366
String str = "aaa";
"new"って文字列が出てこないからOK！！
とかw
368:デフォルトの名無しさん
07/02/17 03:27:00
newは世の元凶です
369:デフォルトの名無しさん
07/02/17 03:31:38
さては、コンストラクタがクラスに内包されるのってオブジェクト指向言語自体の設計ミスなんじゃないのかね。
370:359
07/02/17 14:13:51
ネタですたｗ
371:364
07/02/17 16:28:07
ネタだと知っていて罵倒してやりました
すげえ気持ちよかったでつｗｗｗ
372:359
07/02/17 16:53:19
ストレス解消に貢献でき何よりですｗ
373:359
07/02/17 16:53:51
>>369がちょっと興味深いこといったかも。
374:デフォルトの名無しさん
07/02/17 18:04:33
>>359
お前ごときが興味深いだと？
身の程を知れｗｗｗ
興味深いという奴は何も考えてないといってるのと同じｗｗｗ
ちょー気持ちいいーｗｗｗｗｗｗ
375:デフォルトの名無しさん
07/02/17 18:17:34
確かに３５９は頭わるそうだな( ´,_ゝ｀)ﾌﾟｯ
376:デフォルトの名無しさん
07/02/17 19:10:16
>>370
. ｨ
.._ .......､._ _ ／:/l! またまた、ご冗談を
:~""''.>ﾞ' "~ ,､､''‐'､| _
ﾞ､'､::::::ﾉ:::::::_,.-=. _～:、 ／_.}'':,
``､/:::::::::__....,._ `ﾞ'Y' _.ｪ-､....._ ／_ﾞ''iﾞﾉ､ﾉ
,.--l‐''"~..-_'.x-='"ﾞｰ ､`'-､ ,:' ﾉﾞﾉﾌﾞ
" .!-'",／ `'-‐'') /＼ `/ てﾞノ-〈
.-''~ >'ﾞ:: ‐'"ﾞ./ ヽ.,' ~ ／
／/::::: ', / ,:'
377:デフォルトの名無しさん
07/02/17 19:53:21
俺、環境構築（総合テスト＆本番）担当なんだけど、
開発からあがってくるXMLのbeanidがすげー適当で一発で動いたためしがないんだけど
なんかうまいことチェックできるような仕掛けとかないですかね？
378:デフォルトの名無しさん
07/02/17 20:03:53
beanLint
379:デフォルトの名無しさん
07/02/18 21:44:27
チェックのイミがわからんが、Spring IDEだけではだめなの？
380:デフォルトの名無しさん
07/02/19 04:19:54
springのxml helloで死にそうです。
seasarを使うべきでしょうか？
381:某スレ167
07/02/19 17:07:25
……誰も覚えてないコテハン&ちょー遅レスで恐縮だが（笑）
SpringということでなくDIxAOPということでなら、少なくとも今自分が弄ってるEclipse RCPには大いに有用だと思う。
イベントリスナの管理やログ管理オブジェクトの生成の煩雑さには正直ウンザリしてる（苦笑）
（まさに「フレームワーク」として」）アプリケーションの枠組みはEclipse RCP、AOPするための仕組みと割り切ってComposite（SwingだとPanelかな？）の管理にDIxAOPを導入するのはアリだと思う。
……ちなみにPHPもヤる人間なので現在Seasar2で遊んでいるのだが、どーも隔靴掻痒の感が否めん。Springに移行してしまおうかしらん？
一番アテにしていたコンポーネント（Springでは「Bean」かな？の自動登録はEclipse RCPで使えんよーだし。
ただ、それでもS2Daoはスゴいと思う。……ちゃんと動けば（苦笑）
うごかねーだよ、ヒマ見てちょこちょこ動かしてるレベルぢゃ(T_T)
382:デフォルトの名無しさん
07/02/19 22:08:11
なにいいたいのかいみふ
近視眼的で構成力のないコーダーと推測
383:デフォルトの名無しさん
07/02/19 22:15:08
たしかに
384:381
07/02/19 23:24:42
……バレるもんだな、下地の無さは。２ちゃんでもよく考えて書き込まないとボロが出ますな（苦笑
素直に「プレゼンテーション層が変わるだけでビジネス層やプレゼンテーション層は変わらん」と書いてしまえばよかったかな？
ただ、プレゼンテーション層そのものの作り込みにも、意外とDIxAOPが適用できる部分は多いんぢゃね？ と書きたかったんだけど……まぁいいか、またボロが出る前にやめとこう（苦笑
385:デフォルトの名無しさん
07/02/19 23:28:34
>>384
キモイ
386:デフォルトの名無しさん
07/02/19 23:35:52
taglibにインジェクションする仕掛けがSpringに無いのはなんでだろう。
387:デフォルトの名無しさん
07/02/20 00:20:43
キモイ荒らしが来たと聞いてすっ飛んできますた
388:デフォルトの名無しさん
07/02/20 01:44:13
キモイ荒らしが来たと聞いてすっ飛んで通り過ぎます
389:デフォルトの名無しさん
07/02/20 18:32:50
まじきもいな
こんなやつが同じプロジェクトにいなくてよかったよ
まあ、こんなやつがいたら皆で手を組んで出社できなくなるくらい
追い込んじゃうけどねｗｗｗ
390:デフォルトの名無しさん
07/02/20 20:22:03
>>384
天才。
391:381
07/02/20 20:54:34
>>384
あ、typoしてるし（苦笑）
誤：「ビジネス層やプレゼンテーション層は変わらん」
正：「ビジネス層やデータアクセス層は変わらん」
でよろしく。
392:デフォルトの名無しさん
07/02/21 00:12:19
,. -‐ ''" ￣￣ ｀`丶､
i:::::::::::::::::::::::::::::::::::::::::::i |
ｶ ヽ:::_; ‐--､､ ､---､ ;;_:| |
ﾁ `!;{ |ﾄNヽ }.:.:.:| |ヽ' 要
ｶ lf へ、| ､,. へ､ヽ;| | チ
ﾁ ,.-!. <(')' '(')> '=､ | ェ
ｶ .{{〉,| '" , , ` ﾑ }〉 ､ | ッ
ﾁ ／ヾ‐l ,.---､ u i､..ｲ ｀`'| ク
ｶ ,.ィ_" |`''i、 〈ﾖ￣´,〉 / / | や
ﾁ/,ノr:} ヽ ヽ `'三'"／ / ﾑ !!
/ /,.⊥L_ ＼l! ` -‐' / ／ /|
／ / ─‐〈 ｀ヽ､一r''" ! |／￣ !ヽ
r''" .ノ 'ー─〈 ＿＿ -─‐=ﾆ二二) l ／ |
/ （ ､ 二.ﾌ |-ﾆ￣ -─- | | i
393:デフォルトの名無しさん
07/02/21 10:45:03
>>389
俺はそんな暇があったらコード書くよ。
まっとうなフレームワーク作って、個人の作業範囲が明確になるようにする。
それでもついて来れないようなら他のプロジェクトに回ってもらう。
394:デフォルトの名無しさん
07/02/22 03:06:15
>>393
こんなとこ書いてないで手を動かせｗ
395:デフォルトの名無しさん
07/02/22 03:09:42
>>394
おまえ・・・正論すぎると嫌われるぞｗｗｗ
396:デフォルトの名無しさん
07/02/22 10:03:01
wwwって書くバカっぽいwww
397:デフォルトの名無しさん
07/02/24 00:45:13
ビジネスロジックを複数のCommandとして捉え、ChainOfResponsivirityのように次々に呼び出したい。
この設計思想に基づいてSpringを選択するのは正しい？
また、Commandの実行結果によっては次に呼び出すべきCommandが変わる場合もある。
この場合、設定ファイルだけで実現可能？
教えてｴﾛい人
398:デフォルトの名無しさん
07/02/24 00:53:54
Struts
399:デフォルトの名無しさん
07/02/24 00:57:28
>397
spring以前の問題
そんなもん自前でやれ
springは疎結合モジュール間の依存を解決させるためのもの
400:デフォルトの名無しさん
07/02/24 01:00:01
>>397
つ Jakarta Commons Chain
401:デフォルトの名無しさん
07/02/24 01:20:47
>>399,400
サンクス。
DIで上下レイヤー間の粗結合を受け持たせる…って認識でおk？
>>400の言う通りcommons-chainにするわ。
二人ともありがと
402:デフォルトの名無しさん
07/02/24 14:55:12
commons-chainのcommandにinjectionするニーズっていうのは結構あると思うんだけど。
403:デフォルトの名無しさん
07/02/24 15:23:12
5年以上前からこんなしくみつかっとるがな
404:デフォルトの名無しさん
07/02/24 18:58:12
ビジネスロジックは画面単位、イベント単位どんな風に区切るべき？
405:デフォルトの名無しさん
07/02/24 19:09:56
イベント単位じゃ
まだ荒い
406:デフォルトの名無しさん
07/02/24 21:08:32
っていうか１つのビジネスモデル（もしくは更に細かいモデルであったとしても）＝１画面 or １イベントではない
407:デフォルトの名無しさん
07/02/25 05:47:04
>>403
それって自慢？
俺はその前から使ってるがなｗ
408:デフォルトの名無しさん
07/02/25 06:29:27
>>407
それって自慢？
俺はその前から使ってるがなｗ
409:デフォルトの名無しさん
07/02/25 07:37:48
つい画面単位で物を考えてしまうけど、それではうまくいかないかなぁ
410:デフォルトの名無しさん
07/02/25 08:38:51
画面はビジネスモデルのビューなので
大きなくくりのビジネスモデル (1) ← (n) 画面
だけど、イベント単位に考えると、１つのイベントに他のビジネスモデルでも流用可能な
手続きがあったり、そもそも他業務の機能の呼び出しが入ってたりするから、
細かくしておいた方が都合が良いと思うなぁ
業務B画面 Action 業務A 業務B
│ │ | |
├───→.│ ① | |
│ ├──→| ② │
│ ├─────→.│
│← - - - - - - │ | │
① 業務Aで生成されるデータを取得
② ①のデータを使って業務Bの処理を実行
みたいな
411:デフォルトの名無しさん
07/02/25 10:47:59
>>408
それって自慢？
俺はその前から使ってるがなｗ
412:デフォルトの名無しさん
07/02/25 12:52:13
Spring Web Flowってめんどくせえな
413:デフォルトの名無しさん
07/02/25 13:36:03
>>411
それって自慢？
俺はその前から使ってるがなｗ
414:デフォルトの名無しさん
07/02/25 14:07:00
>>413
それって自慢？
俺はその前から使ってるがなｗ
415:デフォルトの名無しさん
07/02/25 14:19:48
>>414
それって自慢？
俺はその前から使ってるがなｗ
416:デフォルトの名無しさん
07/02/25 14:58:52
>>415
それって自慢？
俺はその前から使ってるがなｗ
417:デフォルトの名無しさん
07/02/25 17:40:47
おもしろいとおもってるのか？これだからプログラマーは。
418:デフォルトの名無しさん
07/02/25 18:04:47
合コンで女性陣がポカーンとしてる光景が目に浮かぶなｗ
419:デフォルトの名無しさん
07/02/25 19:02:31
>>41６
それって自慢？
俺はその前から使ってるがなｗ
420:デフォルトの名無しさん
07/02/25 19:34:09
>>419
それって自慢？
俺はその前から使ってるがなｗ
421:デフォルトの名無しさん
07/02/26 04:27:58
>>420
それって自慢？
俺はその前から使ってるがなｗ
422:デフォルトの名無しさん
07/02/26 05:46:40
今度のSpring勉強会で１０分のデモする人ってあっぱれっと殿じゃね？ｗｗｗ
URLﾘﾝｸ(www.atmarkit.co.jp)
勉強会出席して拝見させてもらわなきゃｗｗｗ
もちろんデモじゃなくてあっぱれっと殿をねｗｗｗ
423:デフォルトの名無しさん
07/02/26 10:58:45
Spring勉強会もアッパレット殿とやらも分からん。
424:デフォルトの名無しさん
07/02/27 01:22:45
だああああああああああああああああああああああああああああああああああああああああああああああああああああああああ！！！！！！！！！！
425:デフォルトの名無しさん
07/03/09 01:52:25
SpringMVCはこれから流行ると思うかね？
426:デフォルトの名無しさん
07/03/09 02:18:15
おもわん
427:デフォルトの名無しさん
07/03/09 04:13:32
思います
428:デフォルトの名無しさん
07/03/09 06:36:52
思えば
429:デフォルトの名無しさん
07/03/09 06:53:10
思うとき
430:デフォルトの名無しさん
07/03/09 07:35:44
思え
431:デフォルトの名無しさん
07/03/09 08:57:34
思おう
432:デフォルトの名無しさん
07/03/09 12:39:27
もうWebはいいだろ・・・と思う。
あえてWebで行く時はSpringMVCは悪くない。
433:デフォルトの名無しさん
07/03/09 19:22:45
>もうWebはいいだろ・・・と思う。
はい！消えた！
434:デフォルトの名無しさん
07/03/10 02:33:46
つまんねーなー
435:デフォルトの名無しさん
07/03/10 02:38:16
今日の勉強会レポよろ
436:デフォルトの名無しさん
07/03/10 08:19:06
つURLﾘﾝｸ(d.hatena.ne.jp)
437:デフォルトの名無しさん
07/03/11 11:51:58
>>436
レポート乙
２番目のトーカーに対するツッコミがきついようだが、そんなに納得でけへん内容やったん？
438:デフォルトの名無しさん
07/03/13 22:38:59
URLﾘﾝｸ(code.google.com)
439:デフォルトの名無しさん
07/03/14 05:23:42
これ軽いね
440:デフォルトの名無しさん
07/03/15 04:58:09
super-injectionがいい
441:デフォルトの名無しさん
07/03/18 21:32:16
Springって、netBeansで動くの？
net-sf-springnetbeans-support.nbmをNetBeansにインストールしたけど、この先どうして良いかわからない。
やっぱりエクリプスが良いのかな。
442:デフォルトの名無しさん
07/03/18 22:07:46
Springが動作するのは、IDE上ではなくてJVM上だ。
「Springって、netBeansで動くの？ 」なんて質問は的はずれもいいところ。
443:デフォルトの名無しさん
07/03/18 22:07:51
動かないわけないべ。
eclipseつかえるならとりあえずそっちでやっとけ。何ら問題ないだろ
444:441
07/03/18 22:29:53
>>442-443
とりあえず、ありがとう。
eclipseはプラグイン探しが大変そうなので、敬遠していたけど、All In One Projectがあるので、そっち試してみます。
445:デフォルトの名無しさん
07/03/18 22:45:04
>>444
まぁかまわんが、spring使うときにプラグインなんぞ使ったことないぞ
何の貯めにプラグインがいるんだ？
446:デフォルトの名無しさん
07/03/18 22:50:44
設定ファイル書く時に補完が効けば少し嬉しいんじゃね？くらいだな。
447:デフォルトの名無しさん
07/03/18 22:53:24
このIDEで動きますかと質問をしている時点でプロジェクトの成功はないだろうなぁと思う
448:デフォルトの名無しさん
07/03/18 22:55:34
時代はアノテーション
449:デフォルトの名無しさん
07/03/18 23:37:25
NetBeansって結構ガチガチにライブラリ周りの設定が組み込まれてるから、
標準で入ってないフレームワーク使うとき躊躇するんだよね。
俺もJSFプロジェクト試してみたときに、RIの代わりにMyFaces使う方法がわかんなくて
結局eclipseに逃げたことあるよｗ
450:デフォルトの名無しさん
07/03/19 00:05:17
組み込みのライブラリ使わなければいいだけじゃないか・・・
451:デフォルトの名無しさん
07/03/19 01:20:37
>>449みたいな発言を見ると、IDEでしかコーディングできない弊害を感じてしまう・・・
452:デフォルトの名無しさん
07/03/19 01:41:09
慣れはあるだろうけど>>449見たいなのは特殊だろ
453:デフォルトの名無しさん
07/03/19 08:15:26
>>452
特殊って？
使いにくいとおもったツールを根性で使うのが普通ですか？
454:デフォルトの名無しさん
07/03/19 08:26:58
IDEサポートが得られないならIDEとフレームワークを無理矢理組み合わせる必要はない。
サポートの無いフレームワークの扱いやすさ
Eclipse ＞＞＞＞＞＞＞＞＞＞＞ NetBeans
455:デフォルトの名無しさん
07/03/19 08:31:51
NetBeansはJavaEE標準のアプリをオールインワンで開発できることに重点を置いてる
ように見える。本質的にはフルスペックのJavaEEサーバを使った開発向き
様々なライブラリを組み合わせて使うのには、やはりEclipseが向いてるように思う
456:デフォルトの名無しさん
07/03/19 08:34:32
ふむふむ
457:デフォルトの名無しさん
07/03/19 10:06:47
アノテーション全然使わないまま1.6の時代が来てしまった・・
458:デフォルトの名無しさん
07/03/19 13:07:07
springユーザってたいへんでつねｗｗｗ
459:デフォルトの名無しさん
07/03/19 14:23:38
は？
460:デフォルトの名無しさん
07/03/19 15:28:25
↑たいへんなスプリングユーザｗ
461:デフォルトの名無しさん
07/03/19 15:42:37
よーするにGlassFishだけで動くアプリの開発ならNetBeans、
Springなど非標準のフレームワークを使うならEclipse。
NetBeansでGlassFishなユーザから見るとEclipseでSpringな
ユーザってたいへんでつねwww
ってことか？
462:デフォルトの名無しさん
07/03/19 16:42:59
case by case
463:デフォルトの名無しさん
07/03/19 16:59:10
Java以外でも使うからeclipse
JavaだけやってればいいSpringユーザはラクでいいね
464:デフォルトの名無しさん
07/03/19 17:03:03
springユーザがJavaだけやってればいいケースも少ないだろｗｗｗ
465:デフォルトの名無しさん
07/03/19 17:04:07
明らかにSpringを分かってない発言が繰り返されてるが
一体どんなものをイメージしてるのか、興味は湧く。
466:デフォルトの名無しさん
07/03/19 17:41:47
わかってる振りしている発言の開始か？
467:デフォルトの名無しさん
07/03/19 21:28:26
っていうかSpring以前に、いまだに１.４だぁ───！！！！
アノテーションてなんだぁ───！！！！
DIってなんだぁ───！！！！
俺終わった─────！！！
468:デフォルトの名無しさん
07/03/19 22:02:57
EJB3.0の話題はあんまり無いのね。
469:デフォルトの名無しさん
07/03/19 22:20:39
>>467
1.4でもSpring使えるぞ
>>468
Springのスレだからな
470:468
07/03/19 22:27:30
>>469
確かにそうだけど、ム板全体で期待されていないような・・・。
471:デフォルトの名無しさん
07/03/19 22:28:40
いや・・・
世界的に（ｒｙ
472:デフォルトの名無しさん
07/03/19 22:34:56
DIコンテナは背後を隠蔽しないけど
EJB3は裏でうねってるものを
アノテーションで見せないようにするのが
なんつーかもう気持ち悪くて話にならん。
interfaceベースの方が分かりやすい。
何をそんなにも隠蔽したがるのか理解できん。
473:デフォルトの名無しさん
07/03/19 22:45:52
interfaceベースかどうかは関係ないだろ。
EJB3もinterfaceベースで作るのが基本だと思うが。
しかも、EJBコンテナだってDIを管理しているからDIコンテナとも呼べる。
アノテーションでDIの設定をするか、
XML設定ファイルに外出しになっているかの違い程度。
EJB3がまだ流行らないのは、まともな実装のアプリ鯖がまだ少ないからじゃね？
JBoss/WebLogic/WebSphereのJavaEE5完全対応版がリリースされたら、
Hibernate/Spring程度には使われるよ。
474:デフォルトの名無しさん
07/03/19 22:56:14
springとJSFで開発してみようかな・・・。
475:デフォルトの名無しさん
07/03/19 23:09:15
まだglassfishしか対応してないからな
今までのEJBとは別物だから普及するだろうね
どういうものかはSeasar2でTigerアノテーションつけたやつで試してみればいい
Springとは違う考え方でどちらかといえばGoogleGuiceが非常に近い
フィールドインジェクションできるってのは強いと思うよ
ロジックと直接かかわらないプロパティアクセスが消せるし
Springはそれを消すために深い継承してるわけだし
EJB3の一部実装として取り出したJPAは普及は確実か
476:デフォルトの名無しさん
07/03/19 23:10:15
コードに書くのか、外に出てるのかが本質的な違いであって
コードに書いたら、もうDIじゃねーと思うんだけど。
なんであれをDIと呼ぶのか、2年近くたつけどまだ納得できない。
EJB3は流行らないと思うよ。
もう今頃は塗り変わってるはずだったのに、一向にその気配がないし。
JBossだってコアな実装はもう済んでしばらく経つんだから
そんなにいいものだったらボチボチ広まってるはずじゃない？
477:デフォルトの名無しさん
07/03/19 23:20:21
商用AP鯖がまだ出てないと思うぜ
JavaEE5だけじゃなくJava2SE5というコア技術も変わるからかなり慎重だよ
Sunですらまだだしてないし
そもそもJavaEE5がでてまだちょうど1年しかたってないし
TomcatはJavaEE5の対応が今回は遅いね
478:デフォルトの名無しさん
07/03/19 23:41:29
あれ、まだそんなだっけ？＞一年
じゃぁもう少し見てみないと分からんのは確かですね。
479:デフォルトの名無しさん
07/03/20 00:00:02
>>476
インタフェースとかポリモーフィズムって知ってる？
それともアノテーションでDIすると依存関係が密になると思い込んでる？
JBossの実装だってまだRC。業務利用できるレベルの実装が無い現状では
普及してないのも仕方あるまい。
商用鯖リリース待ちだね。
JavaEE5仕様は昨年6月リリースだ。
480:デフォルトの名無しさん
07/03/20 00:16:49
JBossSeamと比べるとかなり見劣りするんだが。。
481:デフォルトの名無しさん
07/03/20 00:25:54
つかそもそも高い鯖買って（フリーもあるけど）EJB使うメリットって何ぞ？
482:デフォルトの名無しさん
07/03/20 02:20:02
>>477
Tomcat担当分はServlet2.5とJSP2.1だから、Tomcat6で既に実装済
EJB3についてはわりかし懐疑的だったけど、NetBeansでGlassFishを動かしてみて
印象が変わった。かなり簡単だし、IDEが標準サポートしてくれるのはやっぱり強みだな
483:デフォルトの名無しさん
07/03/20 02:46:32
今日はずいぶんお盛んだな。
AOPできるミドルウェア開発者が居たにも関わらず、
ドロドロの密結合しちまった現場事例： ｽﾚﾘﾝｸ(prog板:240番)
AOPできるミドルウェア開発者が居て、
疎結合をフレームワーク化した事例： Seasar
この差は何で発生したのか判るか？
484:デフォルトの名無しさん
07/03/20 02:49:10
答：前者はたかひろチーム
後者はひがチーム
485:デフォルトの名無しさん
07/03/20 02:49:55
答はアーキテクトの違い
486:デフォルトの名無しさん
07/03/20 02:54:24
2003年時点で「アーキテクチャーの進化は終わった」とか言い出すような
「見えてない奴」がアーキテクチャ設計に関わった時点で、
そのプロジェクトは終わってるな。
487:デフォルトの名無しさん
07/03/20 02:57:43
さっさとAOPへのコミットを試みたｃ野氏の方が
よっぽど「見えてる奴」なのが事実。
・・・そこで方法論について権利争い始めちゃうのが
ダメっちゃーダメだけど。
488:デフォルトの名無しさん
07/03/20 08:57:49
>>478のしったかぶりにわろたｗ
489:デフォルトの名無しさん
07/03/21 00:57:52
そろそろ S2Dao を Spring で実装して
seasarにご引退いただこうぜ
490:デフォルトの名無しさん
07/03/21 01:04:49
seamはいいな
jsfが好きになった
springがそろそろ引退かもな
491:デフォルトの名無しさん
07/03/21 09:31:44
やっとSpringをかじり始めた・・・・
492:デフォルトの名無しさん
07/03/21 11:25:22
ようやっと季節もSpringになってきたというのに．．．
493:デフォルトの名無しさん
07/03/21 12:50:39
Spring始めるにはいい時期ってことか
494:デフォルトの名無しさん
07/03/21 13:43:28
バネもってこい
495:デフォルトの名無しさん
07/03/21 14:54:08
バッファローマン乙
496:デフォルトの名無しさん
07/03/21 22:41:16
Springの最新のリモートサイトってどこ？
497:デフォルトの名無しさん
07/03/22 10:30:50
右から２つ目のタブ
498:デフォルトの名無しさん
07/03/24 13:49:29
しかしGuiceのあの翻訳は何とかならんのか…。powered by Exciteかと。
499:デフォルトの名無しさん
07/03/25 01:10:44
>>498
自分で訳して公開したら？
言うは易し、行うは・・・ｗｗｗ
500:デフォルトの名無しさん
07/03/28 01:36:05
Spring終わったなSpring・・・・
501:デフォルトの名無しさん
07/03/28 01:45:42
>>498
翻訳されてるのか？
JavaDocとGuiceのソースとサンプルソース見ればだいたいおえるっしょ
Googleの翻訳はExciteが神に見えるくらいひどいのどうにかならんのかな
502:デフォルトの名無しさん
07/03/29 01:49:35
Spring自動登録できねーの？Spring
503:デフォルトの名無しさん
07/03/29 01:57:53
autowire のことか？
504:デフォルトの名無しさん
07/03/29 02:03:37
ちゃう
505:デフォルトの名無しさん
07/03/29 02:06:15
Seasar2みたいなのこと？
506:デフォルトの名無しさん
07/03/29 02:07:24
どちらかっつとGuice
507:デフォルトの名無しさん
07/03/29 02:08:45
デフォルト自動登録ってところがGuice
XMLで定義する場合はSpringでも良い
508:デフォルトの名無しさん
07/03/29 09:45:18
>>507
わかってないね。
Guiceは自動登録ではなく、getInstance()で指定した
クラスまたはキーから@Injectを芋づる式に
解決していくシステム。
@Injectの解決もModuleまたはインターフェースの
アノテーションで指定されているもの。
509:デフォルトの名無しさん
07/03/29 14:40:15
おまえらが話してる用語がさっぱりわからん。俺プログラマとしてｵﾜﾀ＼(^o^)／
510:デフォルトの名無しさん
07/03/29 15:03:45
>>507の知ったかに嫉妬
511:デフォルトの名無しさん
07/03/29 16:14:44
Springはインターフェースを登録できないの?
実装はXML見ればわかるけど、それのアクセサが
どのインターフェースをつかうのかなど継承階層によってはわからないのでは？
512:デフォルトの名無しさん
07/03/31 08:34:49
Springだお
513:デフォルトの名無しさん
07/04/03 02:05:01
Springが人気ないのか、>>512の発言が凍らせたのかｗ
514:デフォルトの名無しさん
07/04/03 02:09:13
guice使えるよguice
515:デフォルトの名無しさん
07/04/03 02:10:29
>>508
Moduleで指定が無くてもGuiceが自力で解決するんだおー
516:デフォルトの名無しさん
07/04/07 20:55:31
がおー
……
517:デフォルトの名無しさん
07/04/09 11:46:22
泣かなかったな、坊主。偉いぞ？
518:デフォルトの名無しさん
07/04/09 11:59:44
頭のおかしな人発見
519:デフォルトの名無しさん
07/04/11 00:18:29
ふむ。
Spring-annotationの1.1betaを試してみた。
ちょっと動いた。
これからWebアプリ1個作ってみる予定。
これでXMLから開放されればいいなぁ・・・。
520:デフォルトの名無しさん
07/04/11 00:51:55
アノテーションでグチャグチャなのも如何なものかと・・・・
521:デフォルトの名無しさん
07/04/11 01:03:12
規定事項
522:519
07/04/11 01:07:01
>>520
XMLでもアノテーションでもグチャグチャにしてくれるﾔｼは
どこにでもいるからね。ｗ
1番使えないのは人間だたりしまふ。
「な、なんじゃこりゃあ～！」みたいな。
523:デフォルトの名無しさん
07/04/11 01:13:04
アノテーションとXMLを旨く使い分けられるフレームワークがいいな
どっちかだけってのはキツイな
524:デフォルトの名無しさん
07/04/12 02:19:11
>>519
ある程度触ったら使用感のレポよろ。
コンポーネント内で完結するならアノテーションも悪くないと思うんだけど
コンポーネント間の関連を記述するには、あまり適さない気がしてならん。
ちょっと触ってみた限りなので、使い方がヘタなのかも知れない。
525:519
07/04/13 13:33:01
>524
やってみまふ。
@Injectionとか出来たかなぁ…。
つーかこの時期にｲﾝﾌﾙｴﾝｻﾞはチトつらいっス。
526:519
07/04/15 16:30:32
>>524
>.コンポーネント内で完結
こっちはOK。
>コンポーネント間の関連を記述
こっちはNG。
あとXMLとアノテーションを上手に使い分けないと、頭の中でごちゃごちゃになりますな。
アノテーション使う時は、あくまでも簡素に。
TOAnnotationXmlApplicationContext と ClassPathXmlApplicationContext を
使い分ければ幸せになれるかも。なれないかも。
@RequestInterceptor というアノテーションもあるのですが、中身が空っぽなんですよね・・・。
さーて、どうしよう・・・。orz
527:デフォルトの名無しさん
07/04/17 22:20:55
最近Springを使い始めた者ですがSpringMVCについて質問です。
SimpleFormControllerはただリンクを貼って呼び出すものなのでしょうか？
requestで値を渡してformViewを表示させ、submitで色々処理したいのですが…。
528:デフォルトの名無しさん
07/04/17 22:27:05
その名のとおりフォームつかうやつだよ
529:デフォルトの名無しさん
07/04/18 00:08:48
ソースの円コーディングUTF-8ってどーよ
530:デフォルトの名無しさん
07/04/18 00:09:18
後場食った
531:デフォルトの名無しさん
07/04/18 01:34:39
>>529
メソッド名や変数名を日本語にしても問題起きないなw
532:デフォルトの名無しさん
07/04/18 01:45:42
>>531
別にUTF8じゃなくても問題起きないよ
クラス名はファイルシステムに依存するので問題おきやすいが
533:デフォルトの名無しさん
07/04/19 22:17:46
Javaエバンジェリスト達のコラムサイトでちょうどそんなようなクイズがあったな
534:デフォルトの名無しさん
07/04/23 22:45:34
サキエルは何番目の使途か？
とか？
535:デフォルトの名無しさん
07/04/24 11:04:37
お前は何を言っているんだ？
536:デフォルトの名無しさん
07/04/26 02:12:32
guiceアゲ
537:デフォルトの名無しさん
07/04/29 02:06:55
guiceアゲ
538:デフォルトの名無しさん
07/04/30 03:16:27
guiceアゲ
539:デフォルトの名無しさん
07/04/30 18:10:33
guiceアゲ
540:デフォルトの名無しさん
07/04/30 18:42:02
guiceアゲ
541:デフォルトの名無しさん
07/05/01 01:49:34
guiceってSpringと比べて何が良いの？
542:デフォルトの名無しさん
07/05/01 01:56:01
そうだね。guiceとSpringを比較した場合、次の相違がある。
仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。
抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。
543:デフォルトの名無しさん
07/05/01 01:58:42
>>542
なるほど～
どっちもどっちってことね。
544:デフォルトの名無しさん
07/05/01 02:13:28
さすがにそれはない
545:デフォルトの名無しさん
07/05/01 10:26:13
ｊuiceアゲ
546:デフォルトの名無しさん
07/05/07 20:19:00
guiceアゲ
547:デフォルトの名無しさん
07/05/07 22:39:35
seasarあげ
548:デフォルトの名無しさん
07/05/07 23:22:10
ソースにコメント入れんやつの作った物なんか使えるかい!
549:デフォルトの名無しさん
07/05/08 01:33:09
ソースに醤油入れんやつの作った物なんか使えるかい!
550:デフォルトの名無しさん
07/05/09 19:22:03
RmiServiceExporter を使って特定の RMI サーバを提供しています。
アクセスが集中した際無尽蔵に増やしていくと落ちてしまうので
スレッド数等で制限したいのですが、何かうまい方法は無いでしょうか。
551:デフォルトの名無しさん
07/05/10 00:34:14
springさげ
552:デフォルトの名無しさん
07/05/12 17:58:31
Interface21 (Spring) gets 10M VC Funding
URLﾘﾝｸ(www.infoq.com)
553:デフォルトの名無しさん
07/06/09 18:08:43
お前らSpring使ってて困ったり悩んだりした時どうしてる？
英語不自由だから本家のフォーラムに質問は辛いんだよね
日本語で親切に教えてくれる人どっかにいないもんかねー
554:デフォルトの名無しさん
07/06/09 19:02:41
甘いな
555:デフォルトの名無しさん
07/06/09 19:08:28
甘いのか…
自力でどうにかする自信ないしSeasarにしようかな
556:デフォルトの名無しさん
07/06/09 19:13:50
コメントもドキュメントも無いからなー
その分じゃ自分でコードを追っかけるのもあれなんじゃない？
557:デフォルトの名無しさん
07/06/09 19:26:09
正直自分でコード追っかけるしかないのは無理
558:デフォルトの名無しさん
07/06/09 19:40:45
じゃあ自分でゴリゴリ作るしかないな
559:デフォルトの名無しさん
07/06/09 19:42:11
つーか転職した方が（ｒｙ
560:デフォルトの名無しさん
07/06/09 20:19:39
>>559
履歴書買ってきますた
561:デフォルトの名無しさん
07/06/09 20:52:26
GJ！！
562:デフォルトの名無しさん
07/06/09 21:24:28
>>560
安心しろ
この業界、プログラムなんて組めないほうが偉くなれる。
学歴はないとダメだけどな
563:デフォルトの名無しさん
07/06/09 21:43:35
>>562
564:デフォルトの名無しさん
07/06/11 23:55:13
>>562
こういう意見をよくみかけるが全く賛同できない
プログラムを書きたくないやつがなぜこの業界にいるのか疑問だからだ
収入もすくないし先行きも不安定なこの業界になぜあえて留まりつづけようとするのか
565:デフォルトの名無しさん
07/06/12 00:57:19
>>564
賛同？ 現実を見たくないだけだろｗ
プログラミングなんてシステム構築のごく一部に過ぎないんだよ
566:デフォルトの名無しさん
07/06/12 00:59:35
プログラム書けるより
レビューできるほうがいいかも
567:デフォルトの名無しさん
07/06/12 01:11:17
>>565
ん？わかりにくかったか？
仕事に喜びがないのに、3K低収入のこの業界に留まり続けるのは何故かと言っている。
>>562が正しいかどうかは、全く関係ない
568:デフォルトの名無しさん
07/06/12 01:28:51
事業企画やらプロジェクトマネジメントやらができるんなら
ＩＴ業界じゃなくてもいいじゃんってことでしょ。同意。
569:デフォルトの名無しさん
07/06/12 01:31:49
>>568
そう、それがいいたかった
570:デフォルトの名無しさん
07/06/12 01:36:24
IT業界で優秀なプロマネでも他の業界じゃ並以下だからとか
571:デフォルトの名無しさん
07/06/12 21:55:33
>>564
収入が少ないのは下請けの下っ端だからだろ？
もしくは派遣
572:デフォルトの名無しさん
07/06/12 22:49:41
ヒント： 構造不況
573:デフォルトの名無しさん
07/06/12 22:55:23
うまく元請け大手SIer(国内メーカー系除く)に潜り込んだら
頭使わなくても高収入なんだから転職する理由はない
拘束時間が長いのは辛いが…
574:デフォルトの名無しさん
07/06/12 23:19:41
大手SIerって、はじめからPGいないだろ
PGからステップアップっていうルートが無いよ
575:デフォルトの名無しさん
07/06/12 23:36:49
社会人経験無いんだから知らなくても仕方ないだろ
576:デフォルトの名無しさん
07/06/13 10:42:52
Spring の話しようぜ
spring-ws がなかなか正式リリースにならんなあ
577:デフォルトの名無しさん
07/06/25 22:54:14
SpringからS2Daoって使えない？
578:デフォルトの名無しさん
07/06/25 23:13:07
>>577
n-ichimuraの日記?
579:デフォルトの名無しさん
07/07/16 05:56:49
昨日からspring使い始めたんだけど、applicationContext.xmlファイルがすごい状態・・・
これって普通？
580:デフォルトの名無しさん
07/07/16 10:24:32
だいたいそうなる。XML Hell。
分割すればちょっとだけマシになるかも。
581:デフォルトの名無しさん
07/07/16 12:22:10
>>579
なにをコンポーネントとして登録するかによる。
初心者のうちはなんでもかんでもコンポーネントとして登録してむちゃくちゃになりやすい
582:デフォルトの名無しさん
07/07/19 00:22:24
>>581
どういうのをコンポーネントとして登録するのがいいのかねえ・・・。
583:デフォルトの名無しさん
07/07/19 00:50:21
ステートレスなサービスやファサード、DAO
が代表的
584:デフォルトの名無しさん
07/07/19 23:05:55
サービスってどういう単位？でわければいいの？
585:デフォルトの名無しさん
07/07/19 23:36:12
ファサードやDAOだったらGuiceでいいや・・・
586:デフォルトの名無しさん
07/07/20 08:36:09
俺は
1. anonymousで可能なfind系
2. anonymousで可能なadd、update系
3. 認証が必要なfind、add、update系
の3種類を作ることが多い。
587:デフォルトの名無しさん
07/07/20 13:21:11
?
588:デフォルトの名無しさん
07/07/20 23:28:59
アホか。基本、全部xmlに入れるべき
DIPはOOの基本原則であって、可能な限り全てのクラスが従うべきもの
って、んなことわかんない奴が使って意味あるのか？
589:デフォルトの名無しさん
07/07/21 01:48:46
今度２年ぶりにJavaでシステムを構築することになったんですが、
springは使うとして、ViewとController周りとORMあたりの
フレームワークってなにがお勧めかしら。
今でも、Struts、Spring、Hibernateなのかしら？
590:デフォルトの名無しさん
07/07/21 04:44:06
>>588
くまー
591:デフォルトの名無しさん
07/07/22 16:59:22
-‐ '´￣￣｀ヽ､
┏┓┏┓ ┏┓ ┏┳┳┓ ┏┓ ／ ／" ｀ヽ ヽ ＼. ┏┓┏┓
┃┗┛┃┏┛┗━┫┣┻┛┏━┛┗┓ //, '/ ヽﾊ ､ ヽ ┃┃┃┃
┏┛ ┗╋┓┏┓┃┃ ┗━┓┏╋━/. {_{＼ ／ﾘ| ｌ │ i| ━━━┓┃┃┃┃
┃┃┃┏┓┃┃┃┃┣╋━┓ ┃┃┃ ﾚ!小ｌ● ● 从 |、i| ┃┃┃┃┃
┃┃┃┃┃┃┃┃┃┃┗━┓┣┓┗┛┗━ヽ|l⊃ ､_,､_, ⊂⊃ |ﾉ│━━━┛┗┛┗┛
┃┃ ┃┃┃┃┃┃┃ ┏┛┃┗━┓ /⌒ヽ__|ﾍ ゝ._） j /⌒i ! ┏┓┏┓
┗━┛┗┛┗┛┗┛ ┗━┻━┛ ＼ /::::| l＞,､ __, イァ/ /│ ┗┛┗┛
/:::::/| | ヾ:::|三/::{ﾍ､__∧ |
｀ヽ< | | ヾ∨:::/ヾ:::彡'
592:デフォルトの名無しさん
07/07/23 10:39:40
>>589
あんまり変わってない感じがする。
Hibernate のかわりに JPA も視野に入ってきたくらいで。
View/Controller については、そもそもなんでブラウザで動かしたいのかって時代では。
ここ1,2年は数年前に作ったWebアプリを
リッチクライアントで作り直す案件が多いように感じる。
593:デフォルトの名無しさん
07/08/08 11:33:59
Spring2.0入門買って来た。
Spring Web Flowってよさそうなんだけど、使ってる人いる？
594:デフォルトの名無しさん
07/08/10 19:41:39
つかSeasar使わないおまいら、非国民？
595:デフォルトの名無しさん
07/08/10 20:29:51
>>594
釣られクマー
596:デフォルトの名無しさん
07/08/12 10:44:11
>>594
,-┐
,ｨ─､ri´^-─- ､ .┌f^f^f^f^f^f^f^f^f^┐
く / , ,' ヽ ヽ| ~ ~ ~ ~ ~ ~ ~ ~ ~│
`<' / ,'ﾚｲ+tVvヽ!ヽﾄ 知ってるが │
!/ ,' i |' {］ , [}|ヽﾘ 名前が |
`!_{ iﾊﾄ､__iﾌ,ノリ,ｎ 気に入らない |
／/ (^~￣￣∃_ア____n＿＿＿＿＿|
_r''‐〈 `´ｱ/ﾄr─!,.--'
<＿>─}､ `」ﾚ
'ヽ､ ,.ﾍｰｧtｲ
Y､.,___/ |.|
| i `ｰ'i´
597:デフォルトの名無しさん
07/09/19 18:29:44
Struts+Springについて勉強始めました。いまはSpring入門(2.0でないほう)を読んでいます。
Springそのものはバッチ等のUIが絡まないところで使っていましたが、webアプリで使うのは今回がはじめてです。
(Strutsも単体では経験があります)
>>33-45 を見てみましたが、ActionクラスでビジネスオブジェクトをDIで取得する場合、
getBean()ではなくsetter injection のほうがいいということは、
ActionSupport方式ではなく DelegatingActionProxyがいいということですか？
Spring入門によると、DelegatingActionProxy だと struts-config.xml と action-servlet.xml の
2箇所で定義が必要なので面倒という記述があり、私もそう思っていたので、
>>33-45 の流れのメリットがわかりません。
どなたか教えてください
598:デフォルトの名無しさん
07/09/19 18:41:08
>>597
とりあえず↓よめば？
URLﾘﾝｸ(kakutani.com)
メリットはいろいろあるけど、DelegatingActionProxyのほうがテストしやすいよ
599:597
07/09/19 21:56:18
>>598
レスどうもありがとうございます。帰りの電車で読んでみます。
たびたび質問で申し訳ありません。2点聞きたいことがあります。
○1.
Struts + Spring を使ってビジネスロジック(ビジネスオブジェクト)を Action に DI したとしても、
ビジネスオブジェクトのメソッドの引数は web 層を引きずってはならないから
public Interface KeiyakuService {
KeiyakuInfo getKeiyakuInfo(String keiyakuId, String bushoCode, Date nendo);
}
みたいに細かく切り出しますが(ActionFormをそのまま渡すなどしない)、Struts + Spring 連携をしたとしても、
Action の execute() の最初のほうで、ビジネスロジックを呼び出す前に
ActionForm から HTML Form で入力された入力値をせっせと取り出す作業は変わらない、という認識はあってますか？
# Spring とは直接関係ありませんが、ビジネスロジックやユーティリティクラスに
# ActionForm や HttpServlet を引きずりこまないように＆楽するために、
# reflection(BeanUtils)を使って ActionForm からEntityクラスへの変換クラスを
# 自作して使ってますが、もうすこしどうにかならないかなと思う
○2.
DelegatingActionProxy から Action に処理が移っても、Action クラスは Struts を
生で使うときと同じようにスレッドセーフにしておかないといけないと理解してますが、
Actionクラスにビジネスオブジェクトを DI する場合、ビジネスオブジェクトもスレッドセーフに
作っておかないといけないのでしょうか？
・Actionクラスはインスタンスがひとつだけ
→ActionクラスのフィールドにビジネスオブジェクトのインスタンスがDIされるので、
そのActionに同時アクセスがあった場合、ビジネスオブジェクトの単一のインスタンスが
すべてのアクセスのスレッドで使いまわされる？
600:デフォルトの名無しさん
07/09/20 19:58:01
>>599
598氏じゃないが。
Q1 はその認識であってる。詰め替えがアホらしいのは確かだが、
ある程度自動化するフレームワークも出てくるだろうし、あるいは自分で作ってもいい。
Q2 については「ステートレス万歳」の方向が良いかと。
ステートフルなロジックを作成して、スレッドセーフになってるか、その必要があるかに時間費やすよりも、
そのロジックをストートレスに出来ないかを考えた方が、早くて確実で見通しが良い。時が多いと思う。
601:デフォルトの名無しさん
07/09/20 23:26:42
時は皆に平等です。
602:デフォルトの名無しさん
07/09/21 01:22:23
>>599
598だが。
>>600さんに同意です。
ビジネスロジックにリッチドメインモデルを使う場合以外は
スレッドセーフを徹底すべきでしょうね
603:デフォルトの名無しさん
07/09/26 17:35:59
>>599
dozer使っとけよ・・・
604:デフォルトの名無しさん
07/10/06 15:53:03
Struts + Springなら、AutowiringRequestProcessorもありかと
605:デフォルトの名無しさん
07/10/18 11:16:42
URLﾘﾝｸ(d.hatena.ne.jp)
上記サイト通りやったのですが、最後のInternalResourceViewResolverの定義がうまく行きません。
どうしてでしょうか？
実際のソースは以下の通りです。
<bean id="exampleController" class="example.ExampleController"/>
<bean id="secondController" class="example.SecondController"/>
<bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<props>
<prop key="/test.html">exampleController</prop>
<prop key="/test2.html">secondController</prop>
</props>
</property>
</bean>
<!--ViewResolverを使う場合：何故か出来ない-->
<bean id="viewResolver"
class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="viewClass"><value>org.springframework.web.servlet.view.JstlView</value></property>
<property name="prefix"><value>/WEB-INF/jsp/</value></property>
<property name="suffix"><value>.jsp</value></property>
</bean>
606:デフォルトの名無しさん
07/10/18 11:18:19
public class ExampleController implements Controller {
/**
* @see org.springframework.web.servlet.mvc.Controller#handleRequest(javax.servlet.http.HttpServletRequest,
* javax.servlet.http.HttpServletResponse)
*/
public ModelAndView handleRequest(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
// return new ModelAndView("/WEB-INF/jsp/test.jsp");
// ViewResolver
return new ModelAndView("test");
}
}
607:デフォルトの名無しさん
07/10/18 11:18:53
エラーは以下のようなものです。
致命的: サーブレット example のServlet.service()が例外を投げました
java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/fmt/LocalizationContext
at org.springframework.web.servlet.support.JstlUtils.exposeLocalizationContext(JstlUtils.java:83)
at org.springframework.web.servlet.view.JstlView.exposeHelpers(JstlView.java:82)
at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:90)
at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:246)
at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1000)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:761)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:684)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:394)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:348)
608:デフォルトの名無しさん
07/10/18 11:22:44
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Unknown Source)
609:デフォルトの名無しさん
07/10/18 11:37:50
実行時にJSTLの実装ライブラリが無いんじゃないか？
アプリケーションサーバに含まれているか、あるいはアプリケーションの/WEB-INF/libに含まれているか確認。
610:デフォルトの名無しさん
07/10/27 21:45:00
最近の狛犬もどきのカリスマ
今度はJPA仮想敵で俺達サイコーやってます。
「*2JDBC」のセールストークでマーチン・ファウラーの
「流暢なインターフェイス」引用してますが、JPAの
インターフェイスをパクっている時点で既に論理的に破綻してます。
JPAベースで流暢なインターフェイスを実現するラッパーは作成可能であり、
流暢なインターフェイスを実装していることが「*2JDBC」のセールスポイント
にならないことは明らか。
CoC(規約重視)マンセーで使った偽太陽etcがユーザ層の拡大に失敗している
からCoCやめてみました、それだけ。
特定のDIコンテナに統合されている時点で「*2JDBC」は個人的には利用対象
外、モノは悪くないとは思うが狛犬もどき２に依存する気にはなれない。
"CoCの本質は最低限の規約で最大限の効果を得る"ことにあり、規約でがんじ
がらめにしている時点でCoCを語る資格はない。
偽太陽をみるとわかると思うが「狛犬もどき」はCoCの本質を理解していない。
例えば、偽太陽の属性の扱いまわり、実装で楽をするためにあんな変な規約
を導入しているとしか思えない。
Clickマンセーな人でも偽太陽マンセーな人は少なく、狛犬もどきの信者だけが
偽太陽マンセー。
狛犬もどきの失敗は「狛犬もどき２」の中で閉じた世界を構築していること。
外側からみると、狛犬もどきの信者はハイレベルとは呼べないと感じる。
「"*2JDBC"が流暢なインターフェイスを実装しているから流暢なインターフェイス
でないJPAより優れている」等のセールストークに騙される時点でおわってる。
「狛犬もどき」自体の開発者のうちカリスマ他数名はハイレベル(?)なんだろうが...。
新しいプロダクトをリリースする度に行われる「セールストーク」の質の低さには
ウンザリ。
611:デフォルトの名無しさん
07/10/27 21:59:18
Seasarの煽りuzeee
612:デフォルトの名無しさん
07/10/27 23:01:09
ウザイと言うか・・・こんな書き方するってずいぶんとまぁ・・・
池沼にはウンザリ。
613:デフォルトの名無しさん
07/10/27 23:11:37
狛犬とか太陽とかいうのはうざいが、同意する部分あるな
614:デフォルトの名無しさん
07/10/27 23:20:57
ASIP乙
615:デフォルトの名無しさん
07/10/29 11:45:59
内容に自身があるなら隠語や伏字やめれ。読みにくい。
どっかのスレの雰囲気を持ち込まれても困る。
616:デフォルトの名無しさん
07/10/29 17:40:33
sessionFormをtrueに設定したんですが、このあとどうやってsessionを取得すればいいのでしょうか？
どなたか教えてください。
617:デフォルトの名無しさん
07/12/07 00:13:54
Scopeのsingletonとglocal sessionの違いを確認できるような
構成ってどんなものがあるでしょうか？違いがわからんです。
618:デフォルトの名無しさん
07/12/15 13:49:13
前期のシグルイに今期のカイジ、渋い作品は探せばいくらでもあるが単にﾔｼらの趣向に合わんだけだろ
萌えとかいったって細かい趣向の違いがあって妹13人とか30人に囲まれたいﾔｼには今期はもの足りんだろうしな
619:デフォルトの名無しさん
07/12/15 15:30:00
なんというSpring萌・・・
Spring2.5はすごいな
GuiceやSeasar2の価値をゼロにしたかもしれん
620:デフォルトの名無しさん
07/12/15 17:05:15
>>619
どのへんが？
621:デフォルトの名無しさん
07/12/15 17:18:02
>>620
妹13人とか30人に囲まれたいとか
622:デフォルトの名無しさん
07/12/17 08:09:32
基本的にコアは 1.1.x で完成していて、
1.2.x 以降は設定ファイルの書式が若干良くなったり
かえって悪くなったりしてるだけじゃなかろうか。
(XML 名前空間は使いにくいから失敗だと思う。
機械が読むには悪くないけど、人間が書くには疲れる。)
spring-ws や spring-webflow みたいなサブプロジェクトが
どれだけ完成度高めていくかと、
新たに面白いサブプロジェクト生まれないかなぁって辺りに関心がある。
コアのバージョンはもうどうでも良いって言うか。
Guice や Sesar2 はハナから問題外じゃね？
デファクト取っちまってるプロダクトがどうしたって強いし。
あとは Rails にだまされてる人達が
どれだけ早く DI の妥当さに気がつくかだけでしょ。
623:デフォルトの名無しさん
07/12/18 01:24:31
膣内射精断面図はまだですか？
624:デフォルトの名無しさん
07/12/18 03:18:04
>>623
明日の１３時にアルタ前で、直接手渡します。
ロッドジョンソンのTシャツを着て待っていてください。
625:デフォルトの名無しさん
07/12/29 01:59:06
相も変わらずG'sは狂ってるな。１９人の姉妹だとよ
URLﾘﾝｸ(gs.dengekinet.com)
626:デフォルトの名無しさん
08/01/09 00:55:08
オレの嫁達紹介 全員判別できたら通報する
ちょっと生意気だけどご近所の子のアイたんって子がマジ可愛い。リボンの似合うキュートガールなんだ＾＾
オレの同居人のかなみたんも可愛いすぐるんだ。なんか思考読まれてるんじゃないかってほど、的確に動いてくれて役に立つし＾＾
他の女の子の話してると、彼女のロゼッタたんがディアボロで殴ってくるからそろそろやめとくか＾＾
オレのいとこのあすたんも可愛いんだ。貧乏だから色々支援してあげてる＾＾
ちょっと怖いけどオレにとりついてる幽霊のコゼットたんも好き。今はコップの中に引きこもってでてこないけどさ＾＾
妹のクリスマスたんに女の子の話するとちょっと動揺したように逃げてくんだよね、普段読まないのにこっそりファッションの本とか読んでるの見たときはちょっと萌えた＾＾
近所に住んでる蘭たんはすごいポーカーフェイスでいっつも狐のお面をかぶってるんだけど、オレには優しさと笑顔を見せてくれるんだよね。可愛いすぐるぜ＾＾
幼馴染のテッサてんはクリスマスたんよりおいしい料理を食べさせてあげる！とか毎日いきまいてるけどなんでだろう＾＾
でもドジだからいっつもなにか間違えるんだよなぁ。まぁそこが可愛かったりするけど＾＾
同じ職場のルリたんは皮肉屋でいっつもオレのこと小ばかにしてるけど。本当はオレにぞっこんなのは裏とれてるんだなぁ＾＾
お隣に住んでるアナたんは苗字で呼ぶと怒るんだけど、それがまた可愛くてやめられないんだ＾＾
クリスマスプレゼントでうちにきた電波系の自称オレの妹ちょこたんは本当に純粋無垢で可愛いんだなぁ＾＾
これまた近所の桜田さん家に遊びにくる金糸雀たんも激萌えなんだ。ちょっと頭足りないから、口喧嘩でいじめるのが楽しい＾＾
前ジャングルに行ったとき出あった女の子のマリィっていう子も可愛いんだなぁ。好きな人がいたみたいだけど振り向いてくれないらしく
オレが甘い言葉囁いたらすぐ落ちた。でもずっといるとちょっと疲れる子なんだよね＾＾
以上13人がオレの嫁