Java Spring Frameworkを語るスレ

Java Spring Framewor ..

97:名無しさん＠そうだ選挙に行こう
04/07/11 20:14
で、>>96から見てSpringはどうなのさ

98:デフォルトの名無しさん
04/07/11 23:42
IoCコンテナ作ってりゃ大なり小なりSpringは意識するんじゃないのかな
それは仕方ないことだし別に悪いことじゃないと思うけどね
JBossだって他のJ2EEサーバには負けねーってノリだけど器が小さいとは思わない
似たようなもんだろ

99:デフォルトの名無しさん
04/07/11 23:52
>>98
JBossは、自作自演してたりするけどな。

100:デフォルトの名無しさん
04/07/12 12:10
100get

101:デフォルトの名無しさん
04/07/16 21:02
>正直S2はひが氏以外に大した人材がいない（いても強くコミットしてない）
>から先は無いと思う。

最近開発を(一部)分担したらしいが、それがうまくいくかどうか。
失敗すればHORBの二の舞か。

102:デフォルトの名無しさん
04/07/16 21:08
HORBってあったねぇ。

あれの失敗の原因って何だろ。

・開発者１人に依存しすぎ、開発者発病であぼーん
・そもそも分散オブジェクトに需要がなかった

103:デフォルトの名無しさん
04/07/16 23:57
OMG様のCORBAとSUN本家のRMIの2強がいちゃあ、
黄色い猿が作ったモンが広がる余地はないだろ。

104:デフォルトの名無しさん
04/07/17 00:03
>>102
標準性が必要な分散オブジェクト技術としては、弱すぎた。

105:103
04/07/17 00:05
あぁ、それと、当時はまだgoogleもなく、常時接続も極めて少なく、インターネット上の情報が少なかった
今みたいなインターネットありきじゃなく、雑誌の情報が主で、プロモーションができてなかったんじゃないかと。

今であれば、それなりに使えたかも。
とりあえず情報少なすぎた。

106:デフォルトの名無しさん
04/07/17 00:54
HORBってclassファイルのバイトコードエンジニアリングでスタブを生成してなかったっけ。

今はそこらじゅうのAOP対応コンテナでやってるけど、当時としては画期的だったような。

107:デフォルトの名無しさん
04/07/17 01:16
>>101
優しいなもまいは。そうやって使いもしないプロダクトにまで気を使ってやるもまいの優しさが報われるのを祈っているぞ

108:デフォルトの名無しさん
04/07/17 07:34
>>107
どうも。
とりあえず生暖かく見守ります。

109:デフォルトの名無しさん
04/07/20 10:13
Springで質問です。

JDBCTemplate.query(String,RowCallbackHandler)というメソッドで
RowCallbackHandlerインターフェースの実装を渡すと、
ResultSetの件数分だけRowCallbackHandlerのprocessRow(ResultSet)が
呼ばれるんですが、これってデータがものすごい数あった場合、
ものすごい回数呼ばれるじゃないですか。

それって性能的にどうなんでしょうか。一回のprocessRowの中でwhileループ
まわしてすべて終わらしてしまうのはよくないですか?

110:デフォルトの名無しさん
04/07/20 11:35
>>109
URLﾘﾝｸ(d.hatena.ne.jp)
↑よみましょう

111:デフォルトの名無しさん
04/07/21 22:38
Seasarのサイトを見てみた。
「易しさと優しさ」がテーマだと書いてあった。
ダウンロードページを見てみた。
頭のいい人が考える「易しさと優しさ」っていうのは、所詮あんなもんなんだ、と思った。

112:デフォルトの名無しさん
04/07/21 22:50
選択肢が多いことは即ちわかりにくい、という大原則をわかってないらしい。
何ダウンロードすればいいのか、わからない。

あぁ、わかりやすさはテーマではないのか。
わかってる人に易しく優しければいいんだな。

113:デフォルトの名無しさん
04/07/21 23:18
彡ミミミミ彡彡
巛巛巛巛彡彡　　＜　こいつマジでアホやな
　　　　　　　　 i　　　　　　　＿＿＿＿＿＿＿＿＿＿＿＿
　　　⌒　　 ⌒ |　　　　　　 |　＿＿＿＿＿＿＿＿＿＿＿
　 -･=- ,　(-･=-　　　　　 |　|
　　⌒ ) ･･)(　^ヽ　　　　　 |　|
　　　┏━┓　|　　　　　 |　|112 名前：デフォルトの名無しさん
　　 ┃ヽ三ﾉ ┃ |.　　　　　 |　|　　選択肢が多いことは即ちわかりにくい
.　　　 ┗━┛　ﾉ　　　　 |　|　　 ,ｨー-ーｭｧ
｀- ､＿ー-ーｲ/.　　　　　 |　| ／　'｀'｀'｀ヽ
｀￣ l　l　￣｀ヽ､.　　　　　 |／　　　　　ｨソ
　　　ヽヽ　　　　　>ヽ　　／　　　　　,ノ＿＿＿＿＿＿＿＿
　　　＼＼　　／　ノ＼／ヽ､＿ ,,,ｨ'"＿＿＿＿＿＿＿＿＿
　ﾝ　　　＼｀´　／　ﾝ　　　　　 /ﾆﾕﾆﾕﾆﾕﾆﾕﾆﾕﾆﾕﾆﾕﾆﾕ
　　＼　／　／　　　　　　　　 /ｴｴｴｴｴｴｴｴI　ﾛｴｴｴｴｴｴ

114:デフォルトの名無しさん
04/07/22 00:44
>>112
その辺は多分どっちもどっち。
Springのようにすべてが取り込まれる方が良い人も
いるでしょうし、S2のようにコア以外は使う人に意志に任せる
というのもありだと思う。
個人的には必要なのは自分で選べた方が良いけどね。

115:デフォルトの名無しさん
04/07/22 04:29
>>114
無用に古いバージョンがある。

116:デフォルトの名無しさん
04/07/22 04:30
っていうか、本体が一番下にあるのが・・・。

117:デフォルトの名無しさん
04/07/22 19:51
せめてS2本体は別ページに置くか、トップページで最新版へのリンクを明示しておくか。

私的にはMaven使ってビルドするサンプルプロジェクトあれば十分だと思うけど。

（サンプル落としてビルドしたら依存関係を持つプロダクトを全部落としてくるようにする）

118:デフォルトの名無しさん
04/07/22 20:43
トップページではDIコンテナとかAOPがなんのことかわからないとSeasarがなんなのかわからんしね。

119:デフォルトの名無しさん
04/07/22 20:51
頭のいい人が「やさしい」といっても、ふつうの人は理解するのは大変。
そういうことでしょ。

120:デフォルトの名無しさん
04/07/22 21:07
>>119
「わからない」ということがどういうことかわかってないと、「わかりやすい」は難しい。
あの人たちの周りには、「わからない人」というのはいないし、寄ってこないだろうからね。
っていうか、「日本語で書いてある」「ドキュメントがたくさんある」「設定ファイルが単純」ということをもって「易しい」とか「優しい」っていってるだけだね。
「やさしさ」を重要視してるというのなら、「やさしさ」のためにどういう活動や管理をしているか、聞きたいもんだ。
GUIもないのに、「直感的」とか。

MSの、なんも考えずに使える環境とか見てると、やっぱすごく「優しさ」「易しさ」「わかりやすさ」考えられてると思う。

121:デフォルトの名無しさん
04/07/22 22:55
なあ、Javaってまだフレームワーク競争してんの？

122:デフォルトの名無しさん
04/07/23 01:29
>>120
具体的にS2の何がわかりづらいの？

123:デフォルトの名無しさん
04/07/23 01:40
>>81
Apache Mavenならdeployが驚くほど簡単にできるぞ。
まあやってみい？

124:デフォルトの名無しさん
04/07/23 01:45
>>120
GUIのどこが直感的なの？
コマンド探そうとしてアイコンみてもただの絵にしか見えなくて(以下略)

125:デフォルトの名無しさん
04/07/23 01:55
またコマンドライン対GUIネタかよ
とりあえず>>120はvs.netでも使ってろってこった

126:デフォルトの名無しさん
04/07/23 02:21
Maven + Eclipse + MevenideがあればVSﾄﾞﾄﾈﾄなんていらない。

127:デフォルトの名無しさん
04/07/23 02:39
そもそもJavaにGUIを期待してる時点で(ry

128:デフォルトの名無しさん
04/07/23 03:18
Eclipseは例外。
それどころかこれからはすべてが例外になる。

Swingも著しく早くなってきた。
そしてJavaWebStartの本格普及。
Appletに取って代わる技術だ。
そしてJSFによるリッチクライアントだ。

そしてJiniテクノロジーの普及。

129:デフォルトの名無しさん
04/07/23 03:47
Jiniかよ！

130:デフォルトの名無しさん
04/07/23 04:24
＞MSの、なんも考えずに使える環境
そのせいでクソシステムが乱造されてるわけだが

131:デフォルトの名無しさん
04/07/23 05:57
>>120
その単純な設定ファイルを見て、実際にどう処理されるか、わからないと使えない。
こういう場合は、こう使え！という実例があればいいけど、当面期待できそうにない。
DIコンテナとかAOPを力説されても、ひいちゃうな。

132:デフォルトの名無しさん
04/07/23 06:40
>>130
それはクソシステムの乱造とは関係ありません。

133:デフォルトの名無しさん
04/07/23 08:27
AOPとかDIコンテナとかの便利さは使い方はすでにわかってる人に対して、こんな簡単に使えますよ、っていってるんだよね。

断っとくけど、Seasarはいいものだとは思う。わかってれば簡単だし。
周辺技術との連携も充実してきてるから、わかってれば使い易いし。

134:デフォルトの名無しさん
04/07/23 15:11
>>131
＞DIコンテナとかAOPを力説されても、ひいちゃうな。
DIやAOPがSpringの売りですが何か？

135:デフォルトの名無しさん
04/07/23 15:20
Springの方は、「優しさを重視」とかインチキくさいこといいながらトップページに概要も書いてない、ということがないからおけ。

136:デフォルトの名無しさん
04/07/23 15:37
Springでいいじゃん。

137:デフォルトの名無しさん
04/07/23 16:00
>>132
だったら.netでちゃんとしたシステム作ってればいいだろ
何も考えずに使えるから何も考えずに行き当たりばったりに作る馬鹿が増えたんだよ
MSマンセーならJava使わなくていいじゃん

138:デフォルトの名無しさん
04/07/23 16:26
>>137
なにかにマンセーになるのは必須なのですか？
.netも、Javaとは別の性格でいいところはいいし、ちゃんとすればちゃんとしたものができるし、Javaでもちゃんとしなければクソシステムができる。
たとえMSマンセーであってもJavaがいいときにJava使うことはいいことだ。

139:デフォルトの名無しさん
04/07/23 16:31
で結局SpringはどうなんだYO

140:デフォルトの名無しさん
04/07/23 16:48
SpringのスレでMSを引き合いに出すのもどうかとおもうがな

141:デフォルトの名無しさん
04/07/23 16:52
統合開発環境として、MSのものはとっても優れてるから。
SpringなりSeasarなりも、いろんな技術を統合するためのフレームワークを目指してそうな気配だから、MSの開発環境並に統合された環境を用意してくれれば幸せ。

142:デフォルトの名無しさん
04/07/23 18:09
その辺はEclipseと比較すべきだろう
プラグインの取り組みはされているようだけど
そもそもEclipseがVS.netのように敷居が低いとは思えんしなあ

143:デフォルトの名無しさん
04/07/23 21:21
SEASERみたいなマイナーなやつに粘着するやつウザイ
もっとSpringの情報が欲しい。実際に仕事で使ってるやつとかの書き込みキボンヌ

144:デフォルトの名無しさん
04/07/23 21:42
Springも充分マイナーだと思う・・・

145:デフォルトの名無しさん
04/07/23 23:28
Springがマイナーとはいわないだろう
J2EEに与えたインパクトは大きいよ

146:デフォルトの名無しさん
04/07/24 10:44
>>142
そこでNetBeansですよ。
NetBeans4.0次第だけどな。

147:デフォルトの名無しさん
04/07/24 23:08
コンテナとIDEのはなしをまぜこぜにしてもなあ

148:デフォルトの名無しさん
04/07/25 00:14
>>145

各種O/R Mappingフレームワークに多大な影響を与えたと思われるWebObjectsは未だマイナーだと思われ。

って言うと信者が湧いてきそうだな。

149:デフォルトの名無しさん
04/07/25 00:16
その代わりTapestryとCayenneが注目されてるからいいんじゃない＞WO

150:デフォルトの名無しさん
04/07/25 00:48
>>148
作ったところが作ったところだから。
どんなに広まっても、マイナーということになる運命。

151:デフォルトの名無しさん
04/07/26 10:05
>>141
> 統合開発環境として、MSのものはとっても優れてるから。
M$のVS.NETなんてEmacs + GNU makeと比べたら大したことねえよ。

最近ではEclipseのプラグイン拡張が凄いことになっている。
しかもApache Antと併用できる上に、Apache Mavenという強力なプロジェクト管理ツールが登場した。
こいつもEclipseで使える。

しかもサーバ関係はＭ＄は弱い。Javaのほうが強しだな。
WebServicesで.NETはJavaに敗れたわけだし。

152:デフォルトの名無しさん
04/07/26 15:38
Eclipseのプラグイン拡張は、結局それぞれのプラグインをちゃんと把握してないといけないので、MSの統合環境みたいに、なにも考えなくてもいろんな技術が統合されたものができるというわけにはいかない。
Emacs + makeの場合、ほんとにそれぞれの項目を理解していないと使えない。
それぞれの項目同士の連携は、自分で考える必要がある。

それぞれの部品単位ではMS以外の環境が優れているかもしれないけど、「統合」という点ではMSの環境が優れている。
EclipseもEmacsも、たくさんの機能がひとつの環境から使える、という程度でしかない。

153:デフォルトの名無しさん
04/07/26 18:17
>>152
> Eclipseのプラグイン拡張は、結局それぞれのプラグインをちゃんと把握してないといけないので、MSの統合環境みたいに、なにも考えなくてもいろんな技術が統合されたものができるというわけにはいかない。
アホか。VS.NETにもプラグイン拡張があるぞ。
Eclipseのプラグインの把握はたいしたことがないぞ。
ちゃんとドキュメントは揃っているんだし。説明書をよめばだいたいわかる、どころか読まなくてもすぐに使えるんだし。
開発経験の無いド素人じゃあるまいし、エンジニアがそんなことも把握できないでどうするんだか。

> それぞれの部品単位ではMS以外の環境が優れているかもしれないけど、「統合」という点ではMSの環境が優れている。
> EclipseもEmacsも、たくさんの機能がひとつの環境から使える、という程度でしかない。

どこをどう統合したんだか。
VS.NETは2004になってからやっとリファクタリングなどのような
Eclipseに追いついた機能を手に入れたんだし。

154:デフォルトの名無しさん
04/07/26 18:24
>>153
WebサービスしらなくてもWebサービスつくれちゃうとか。
データベースのテーブルデータを取ってくるのをWebサービスにしてVBに貼り付けとか、簡単にできた気がする。
StrutsものにしてもHibernaterものにしても、それぞれが何かをちゃんと把握してないと使えない気がする。
Eclipseではなくて、Javaの問題なんだけど、そういったそれぞれのコンポーネントが縦割りで独立していて、連携をとるのに知識が求められる。
MSの技術は、それぞれは大したことないんだけど、それぞれを意識せずに連携できる。

それを解消しようとするものとして、Springがあるんだろうけど。

155:デフォルトの名無しさん
04/07/26 19:11
>>154

> WebサービスしらなくてもWebサービスつくれちゃうとか。

それもどうかと思うが

> それを解消しようとするものとして、Springがあるんだろうけど。

それも違うような気がするが

156:デフォルトの名無しさん
04/07/26 19:43
>>155
そう？
StrutsやらHibernateやらのアーキテクチャの違いを、IoCを介することで一貫性を保ちやすくする、という目的もあると思うんだけど。

157:デフォルトの名無しさん
04/07/26 21:04
上手く説明できないが違和感を感じる＞IoCを介してアーキテクチャの一貫性を保つ

158:デフォルトの名無しさん
04/07/26 21:28
>>157

違和感を感じるにも違和感を覚える。

159:デフォルトの名無しさん
04/07/26 21:53
このスレで一番参考になったレスかもしれない

160:デフォルトの名無しさん
04/07/26 22:26
>>157
SpringではSpringDAOとかSpringORMとかSpringMVCとかで
SeasarではS2DAOとかS2HibernateとかS2Strutsとかで

なんか、統一的な利用方法を提供しようとしてると思う。
基本的にJavaWorld2004/7の受け売り。

161:デフォルトの名無しさん
04/07/30 00:34
>>160

>SpringではSpringDAOとかSpringORMとかSpringMVCとかで
>SeasarではS2DAOとかS2HibernateとかS2Strutsとかで
これではアーキテクチャは統一されていないよね？
単一のフレームワークにて、ORMやJDBCフレームワークが利用できるのも統一的な利用方法とは
言えないのでは？

プレゼンテーション-ビジネス-パーシステンス層、全てにおいてIoCをベースとしたフレームワークを
利用できる為、アプリケーションにおけるアーキテクチャの統一性がはかれる。
またIoCを介することで、アプリケーションが個別のフレームワーク(Struts,Hibernate・・・)を意識しなくて
よいアーキテクチャを設計しやすくなると漏れは思っているがどうよ？

162:デフォルトの名無しさん
04/08/10 02:34
S2ネタはこっちでどうぞ
国産オープンソースDIコンテナSeasar V2(S2)
ｽﾚﾘﾝｸ(tech板)

163:デフォルトの名無しさん
04/09/08 22:38
1.1もでたことだし

164:デフォルトの名無しさん
04/09/11 17:16:39
ところで、SpringStrutsを使うとき、struts-configやapplicationContextをXDocletでは管理できんですか？

165:デフォルトの名無しさん
04/09/12 10:31:07
未だになんでSpringがいいのか全然分からないんだけど。
あんな別途にXML書いてアホかと思う。利点が見えない。
誰かSpringの利点が書いてあるリソース教えてください。
それか語ってください。

166:デフォルトの名無しさん
04/09/12 11:45:37
利点が見えないのはアホかと思うが、XML書いてアホかと思うのは同意しまくり。
SpringStrutsなんか使った日には、XDocletも使えず、struts-configとapplicationContextを書き換える必要がある。
かなり間違えやすそう。
テストが楽になるとはいうが、XML定義が正しいことのテストはどうするのさ？

利点はここでも見てろ。
URLﾘﾝｸ(wiki.bmedianode.com)

ようするに一極集中ってイイね、という話だ。

167:デフォルトの名無しさん
04/09/12 13:29:56
DIはEoDではない、と思われ。

168:デフォルトの名無しさん
04/09/12 21:17:16
>>165
Spring + Struts + Hibernateのコード書いてみたが、コード自体は非常にすっきりした。
いかにオブジェクトの生成・保持・伝達にコードが必要だったかわかる。

だから、逆に、Struts+HibernateでDI使わないとすると、あんないろんな場所でオブジェクトの生成取得コード書いて、必死に受け渡しして慎重に保持するのを見るとアホかと思う。
ということが言えるかもしれない。

169:デフォルトの名無しさん
04/09/13 00:52:43
そもそもWebインターフェースで複雑な業務を扱うのはいかがなかものか、と。

170:デフォルトの名無しさん
04/09/13 01:11:52
>>169
一般向けだと、現状Webインターフェイス以外の選択肢はないと思うが。

171:デフォルトの名無しさん
04/09/13 20:53:56
この本、
今現在webl○gicとN○Lの訳わかんねーﾌﾚｰﾑﾜｰｸ使ってﾑｶつきながら巨大webｱﾌﾟﾘ作ってるおれは
素直に感動した。

【軽快なJava】
URLﾘﾝｸ(www.esbooks.co.jp)

172:デフォルトの名無しさん
04/09/13 21:05:10
web10gicの変数名クラス名がやたら癇に障る

173:デフォルトの名無しさん
04/09/13 23:02:12
>>171
おれもその本買ってきた。J2EEはプログラマーの臨界点を超えて
複雑すぎるんじゃないかと思ってたのをそのまんま明快に書いてて
楽しい。

174:デフォルトの名無しさん
04/09/14 01:30:09
しかし、翻訳者がきらい。
へんな「翻訳者注」ない？

175:デフォルトの名無しさん
04/09/14 01:33:10
>>174
うむ、翻訳者がいけてないのは事実。こんなとこに訳注はいらんわい、
てなところにまで訳注があって、しかも日本語が意味不明。

最初、翻訳文なんで原文が意味不明なのかと思ったら、「訳者注」とか
書いてあるんでびっくりした。

176:デフォルトの名無しさん
04/09/14 01:49:20
えー、そうなの？

177:デフォルトの名無しさん
04/09/15 11:50:42
岩谷か。。。orz

178:デフォルトの名無しさん
04/09/15 19:32:38
>>171
よさげな本じゃな。
翻訳者には期待できないことを覚悟したうえで　
買って読んでみるか

179:デフォルトの名無しさん
04/09/15 23:13:13
おれ岩谷の名前を意識したことなくて、今回あまりの訳注の多さに
びっくりしたんだが、ぐぐってみるとすごいのな。いやびっくり。

180:デフォルトの名無しさん
04/09/16 10:34:40
軽快なJava読んだよ。
でも、はっきりいって Spring Frameworkスレの住人にとって、
今更技術的に役に立つことはないかも。

EJBっていけてないじゃんと思ってるけど、それを口に出すと
「お前がデキないだけ」
「お前のやってる案件が小規模なだけ」
と煽られてストレス溜まってるﾔｼが、自分の考えを再確認するには
いいかもしれない…

181:デフォルトの名無しさん
04/09/16 20:14:22
こんな感じのリストを、プロパティじゃなくbeanとして定義することってできますか？
　 <list>
　　 <bean class="org.apache.struts.util.LabelValueBean">
　　　 <constructor-arg index="0"><value>いらない</value></constructor-arg>
　　　 <constructor-arg index="1"><value>0</value></constructor-arg>
　　 </bean>
　</list>

182:デフォルトの名無しさん
04/09/16 20:47:32
>>180
>軽快なJava読んだよ。

SF小説ですか？

183:デフォルトの名無しさん
04/09/16 22:01:02
話題についていってない人はっけーん。
っつうか、10レス上くらい読めばいいのに。

184:デフォルトの名無しさん
04/09/17 07:17:23
ぼけたつもりなんだろ>>182は
いじめてやるなよ

185:デフォルトの名無しさん
04/09/17 12:48:59
定義ファイルだけど、同じクラスの定義を何個も書くの面倒。
値だけ異なる複数のBeanを定義する方法ってあるの？
例えば、商品クラスのインスタンスを４つ作るみたいな。

186:デフォルトの名無しさん
04/09/17 13:48:25
>>185
コピペ

187:デフォルトの名無しさん
04/09/18 10:10:57
Springからファクトリでクラスをロードするとき、
プログラムからコンストラクタに引数ってわたせない？
HttpRequestわたしたいんですが

188:デフォルトの名無しさん
04/09/19 03:21:59
>>187
あとで渡せばいいじゃん。

189:デフォルトの名無しさん
04/09/24 04:57:45
Spring + StrutsのActionをテストするにはどうするのがいいんだろう？
StrutsTestCaseは使えないし。

190:189
04/09/24 07:06:07
ごめん、StrutsTestCaseで問題なかった。
JNDIデータソースが使えないのが困るだけだ。

191:デフォルトの名無しさん
04/09/24 22:54:26
>>185
共通プロパティを持つ基底ビーンを指定できたら便利だな。

192:デフォルトの名無しさん
04/09/28 20:16:34
ProxyFactoryBeanを通すと生成されるオブジェクトが全部
シングルトンになっちゃうんですが
回避策はありますか？

193:デフォルトの名無しさん
04/09/29 03:59:07
確認してないが、そんなことはないと思うが。
どっちかでsingleton=trueのままなんじゃないの？

194:デフォルトの名無しさん
04/10/04 11:38:15
SeasarとSpringの違いってナニ？

195:デフォルトの名無しさん
04/10/04 11:44:33
Spring
メジャー
関わる人が多い
ドキュメントが揃っている
たぶんメインストリームになる

Seasar
日本ローカル
そこらへんで開発してる
構成ファイルがシンプル高機能
たぶんマイナーなまま

196:デフォルトの名無しさん
04/10/04 13:46:46
S2OpenAMFは使いたいと思ってるんだが

197:デフォルトの名無しさん
04/10/05 02:40:53
Seasar関係者が、自身の日記上でちゃんねらーに宣戦布告。
Seasarスレに本人降臨
ｽﾚﾘﾝｸ(tech板)

198:デフォルトの名無しさん
04/10/05 19:41:09
2つのappcalitionContext.xmlを読み込んでいるんですけど、
1つめのxmlファイルで、あるbeanのpropertyにlistをセットして、
2つめのxmlファイルから、その1つめで定義したbeanを呼び出して、
更にlistに要素を追加することって可能でしょうか？

このビーンはシングルトンです。

199:デフォルトの名無しさん
04/10/05 20:16:52
>>198
xmlファイルはどうとでも分割できるから、一つの定義でかけるならできるんじゃないの？

200:デフォルトの名無しさん
04/10/06 05:40:36
>>199
それが少々複雑なケースで、最初の1.xmlでhibernateで使用する
hbm.xmlをリストでもつLocalSessionFactoryBeanを定義して、
次に読まれる2.xmlで、更に他のhbm.xmlを追加したいような感じです。

で、更に2.xmlでリストに追加したいhbm.xmlの設定は1.xmlで指定した
hbm.xmlのpojoをmany-to-oneで参照しているんですよね・・・

それで2.xmlを読み込む際に1.xmlで追加していたはずのhbm.xmlファイルが
ないよみたいなエラーが出るんですけど、やっぱこれって普通に無理なんですかね？

201:デフォルトの名無しさん
04/10/06 09:15:05
>>200
普通に無理というか、普通にDIを誤解しているだけだと思われ。
Bean定義の継承ができるかどうか、という話だな。
欲しい機能だけど、できるかどうかは知らない。
いまリファレンス読んでる最中だから。

202:デフォルトの名無しさん
04/10/06 12:28:34
parent属性使えばBean定義の継承はできるようだけど、listに追加というのは難しそうだな。
parent属性は型が違ってもいいので便利。
複数のparentを持つにはどうすればいいのかは不明。

203:デフォルトの名無しさん
04/10/13 22:32:02
URLﾘﾝｸ(www.ozacc.com)
のSpring Framework Mail Extension使ったことある人いる？
Velocityを使ったVelocityMailMessageだけオリジナルを元にコピーする
コンストラクタがついてなくて困ってるんだけど。
Springでこれのインスタンス生成してビジネスロジッククラスにセット。
そのままVelocityJavaMailSenderに渡したら
マルチスレッドでごっちゃになってまう。

Singleton=falseにすればいいんだろうけど
その場合ビジネスロジック内にApplicationContextからの取得ロジックを書くことになって
ビジネスロジックがSpringに依存してしまう。
スキルありそうな人だからこれでも普通に使えると思うんだけどどうやればうまく使えるかな？

204:デフォルトの名無しさん
04/10/14 21:57:30
Spring＋Strutsを使うと想定した場合に
サービスクラスとして
FooService implements IFoo
を定義して、
テスト用のサービスクラスとして
FooTestService implements IFoo
のようなものを定義することになると思いますが、

テストごとにテスト用のサービスクラスを変えることって
簡単にできますか？
Cactusと組み合わせた場合とかにデプロイごとに設定ファイル
変えるようなことになってしまわないですか？

205:デフォルトの名無しさん
04/10/15 19:49:37
>>204
できる。
テストケースによって読み込むconfigファイルを変えるだけ。

206:デフォルトの名無しさん
04/10/15 21:41:40
URLﾘﾝｸ(www.amazon.co.jp)

207:デフォルトの名無しさん
04/10/16 11:48:47
じゃ漏れも貼っとくか
URLﾘﾝｸ(www.amazon.co.jp)
ってたけーよ！

208:デフォルトの名無しさん
04/10/17 02:24:42
> 207

まあ、元がイングランドで発売（ポンド->円換算)だからね。。
Professional Java Development with the Spring Framework
の方は、まあ買える値段なんだけど、、、

209:デフォルトの名無しさん
04/10/18 01:25:24
SpringTestCase

URLﾘﾝｸ(blog.ozacc.com)

本家のAbstractDependencyInjectionSpringContextTestsより使いやすそう。
（っていうかこのクラスCVSからとってこないと動かないし・・・・）

210:デフォルトの名無しさん
04/10/27 20:24:42
>>208
めっちゃ亀レスだけど、
amazon.co.jpはポンドとドルのときがあって、
ポンド換算のときはなぜか高い。

ドルになったときに購入するのがおすすめ。

211:デフォルトの名無しさん
04/10/30 00:15:25
日本語版☆⌒ 凵＼(＼･∀･) まだぁ?

212:デフォルトの名無しさん
04/11/01 12:58:29
英語版でいいから欲しいなぁ。。

213:デフォルトの名無しさん
04/11/08 14:43:34
Introduction Advice でわけわかめな状態に。

URLﾘﾝｸ(d.hatena.ne.jp)
この例で言うところの one や two って
もともとのクラス実装(study.Foo)に
ComparableIntroductionInterceptor の実装が足されたものと理解してるんですけど
実際 study.Foo の機能使うときってどうすりゃいいんでしょうか。
one, two に対して単純にキャストするだけでは例外出ちゃうし。

214:デフォルトの名無しさん
04/11/09 02:05:52
(スレ違いだと思うけど、他に書くとこないんで)

PicoConatiner 1.1出ました。
URLﾘﾝｸ(www.picocontainer.org)

215:デフォルトの名無しさん
04/11/09 09:52:08
>>214
Dependncy Injectionを語るスレ
ｽﾚﾘﾝｸ(tech板)

216:デフォルトの名無しさん
04/11/17 00:06:40
XML がソースそのものだと言ったが、もうひとつ。

　DI 廚 = マップ廚

分かるか？実行時解決ﾏﾝｾｰ！？
どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
生成ﾏﾝｾｰとかいう香具師もいたな。何が犠牲になってるかも分からずに
実行時なんたらって言いたいだけちゃうんかと。

なんなら俺が DI + II（Implementation Injection）コンテナでも作ろうか。
コードはもはやインタフェースのみで意識するのは界面仕様のみ。
実装コードは不要。依存性と実装はおまいらの大好きな XML に。
実装の取り替えはもちろん、いつでも修正可能だ。理想的だろ？

217:デフォルトの名無しさん
04/11/17 01:29:51
>>216
必死ですね。だんだんかわいそうになってきた。
何が犠牲になってるの？
マップ厨のときはORM無条件に不要といってたから厨だったんだけど、java.util.Mapでマッピングすること自体は、特に問題ないと思われる。
というか、無条件にDIダメといってる文脈がマップ厨の人と同一人物くさい。

> なんなら俺が DI + II（Implementation Injection）コンテナでも作ろうか。

別に、DIのしくみだけで十分同じことが実装可能なので必要ないけど、面白そうだから、作ってくれ。

218:デフォルトの名無しさん
04/11/17 01:33:02
DIスレでやれ。

219:217
04/11/17 01:37:04
気づかなかったんだよorz

220:デフォルトの名無しさん
04/11/19 09:07:42
ＤＩはある意味ではハシカみたいなもんじゃないかと思います。

思い起こせば、Javaを覚えたてのころは継承を乱用し、
GoF本を読めば(作ってるシステムにとって)意味のないクラスを量産し、
作ってる本人はご満悦ですが、保守する人とかどうしてるんだろう、
と思う今日このごろなコードもかつては作ってしまった気もします。

ハシカやオタフクカゼの困ったところは、「一度かかっておかない」と抗体ができないところ。

新しい設計技法、言語、ツールを知ると使いたくなるというのは
技術者の真っ当な感情だと思いますが、下手に使うとまわりが被害をこうむりますかも。
あと、伝染性がある上に発病期間までに時間があったりすることも。
ちゃんとテストして(使ってみて)、これは行けると踏んでから、
まずはリスクの少ない部分から適用していきましょうと(予防接種)。

生産性と品質に対して何の寄与もしないどころか、
足を引っ張るだけのフレームワークにハメられた僕は
別な何かが見える様になったと思います。

221:デフォルトの名無しさん
04/11/19 09:25:06
ま、コピペもある意味ではハシカみたいなもんじゃないかと思うわけだな。
新しい技術に拒絶感を持つのはなにみたいなもんだろうか

222:デフォルトの名無しさん
04/11/19 10:16:40
待て待て。
ここはネタスレのウォッチスレではないはずだ。

223:デフォルトの名無しさん
04/11/19 13:49:20
ひっそりとヲチするのもいいかもね。

224:デフォルトの名無しさん
04/11/24 13:35:30
DIスレからコピペ。

585 名前：デフォルトの名無しさん本日のレス投稿日：04/11/24 13:04:21
燃料投下。
URLﾘﾝｸ(d.hatena.ne.jp)

225:デフォルトの名無しさん
04/11/24 19:19:32
>>224
ま、そんなもんじゃない？
定義ファイルの分割がよくわからんけど。
要するに、Springじゃひがさんのやりたいことはできない、という程度かと。

226:デフォルトの名無しさん
04/11/24 23:45:25
斜に構えるSpring Frameworkユーザーであった。

227:デフォルトの名無しさん
04/11/24 23:50:23
ネタスレに巻き込まれたくないからな。

228:デフォルトの名無しさん
04/11/25 01:06:39
Java World 1月号に特集出てるね。

229:デフォルトの名無しさん
04/11/25 03:43:35
>> 228

出てた。
約20ページの特集で、Spring+Hibernate、Spring+Strutsについての解説。
割りと初歩的な部分だけど、丁寧に解説されている印象。

230:デフォルトの名無しさん
04/11/25 07:18:10
OGNLは諸刃の剣ということにしておこう。負け惜しみ的に。
たしかにオートバインディングは、名前でのオートバインディングしか使えないね。型によるのは怖い。
定義ファイルの分割については非常に疑問だね。インクルードができない、ということかな。名前空間のこと？
定義ファイルの肥大化に関しては、大規模プロジェクトで大規模に現れるような、シングルトンなクラスばっかりだと、XDoclet使えばいいということにもなるので、実質問題にはならないかと。
ただ、そんときは定義の継承を上手に使う必要があると思う。
逆にいえば、定義の継承ができないSeasar2では、XDocletを使ってクラスにBean定義を埋め込むのと面倒なことが起こるかも。

231:デフォルトの名無しさん
04/11/25 08:47:40
Springｎ 1.1.1のリリースノートに
"import" element for XML bean definitions
ってのがあるんだけど、これがインクルード機能じゃないのかな。詳細をみても
よく分からんかったのだけど。

両方ともまだ使ってなくて、Seasar2は日本語資料が多いし、Springはデファクトになりそうな勢いが
あるということで、最近ずっと資料をよんで検討してました。まだ使ってない人間の感覚からすると、
Springのほうが面倒っぽいですね。直感的でないというか。

なんか微妙に変な感じがするなーと思ってたら、この日記を読んでなるほどと思った。

URLﾘﾝｸ(d.hatena.ne.jp)

ここに書いているとおり、Springの資料を読んでるとなんでもかんでもBeanなんだな、
と感じる。Spring的純粋主義なんでしょうか。一方Seasar2は「作ってるクラス定義自体には
Seasar2フレームワークへの依存関係を絶対もたせない」という方向での純粋主義みたいな
ところがありますね。後者の方が好みかなあ。

232:デフォルトの名無しさん
04/11/25 09:05:32
クラスにはフレームワーク依存のメンバは現れないんだけど、最終的なアプリケーションとしてフレームワークに依存するから、好みの問題なんだよね。
結局フレームワークに依存するんだから、どこにその依存が現れるかは、どうでもいいと思う。
信じる道を行けばいいだけ。
ポリシーが一定してないのは困るけど、両者ともそういうことはないし。

233:デフォルトの名無しさん
04/11/25 23:32:01
漏れも231的な感覚なんだけど、
クラスがフレームワーク依存しなければ、
「再利用しやすいかも」って思うんだよね。

実際に使い込んだわけじゃないから、あくまで幻想だけど。

234:デフォルトの名無しさん
04/11/27 04:00:46
検索するとSpring1.1からOGNL対応っていうのをみかけるんだけど、結局どうなったんだろう？

235:デフォルトの名無しさん
04/11/27 04:28:58
２月ごろ優先度がminorからmajorにあがって、4月ごろ1.1の予定になってたのが、5月にminorにおちつつ1.2予定になって
そして11/16に1.3予定になった形跡がある。
まだまだ先の話か。

236:デフォルトの名無しさん
04/12/06 00:38:33
SpringにしてもSeaser2にしてもJava自体が強い型付け言語なのにも関わらずリフレクションを多様するDIContainerってどおなのよ？
本当に使いやすいのかなあ？

237:デフォルトの名無しさん
04/12/06 00:44:57
強い型付けだからこそ、DIコンテナが生きるんだよ。
ビーン定義ファイルは型による事前検証が可能だしね。

238:デフォルトの名無しさん
04/12/06 00:59:40
コンパイル時に検証できないうえにファクトリでダウンキャストしないといけないのに？

239:デフォルトの名無しさん
04/12/06 03:47:22
>>238
> コンパイル時に検証できないうえにファクトリでダウンキャストしないといけないのに？

周辺ライブラリを使えばダウンキャストは不要。
例えばStrutsのActionに最初から依存Serviceへの
参照がセットされてるとか。

というかむしろダウンキャストしない使い方が標準。

240:デフォルトの名無しさん
04/12/06 11:23:48
>>238
Javaソースを検証するコンパイル時に、Bean定義を検証する必然性はあるの？
別でいいじゃん。

241:デフォルトの名無しさん
04/12/07 00:01:00
ま、大きくなったらわかるさ。

242:デフォルトの名無しさん
04/12/07 01:01:32
>>241
今知りたい。
コンパイル時に検証したい理由。
たとえばantで別の検証タスクを作ってもいいし、簡易なら、単にビーン定義を読み込むだけの検証用プログラムを作ればいいと思うんだが。

243:デフォルトの名無しさん
04/12/09 00:31:01
>>239
なるほど、やっぱダウンキャストは勝手にやってくれって感じだよな

>>242
Javaしか知らん奴には弱い型付けとか言ってもわからんのだろう
藻前は却下

244:デフォルトの名無しさん
04/12/09 01:12:30
>>243
弱い型付けってなんですか？

245:デフォルトの名無しさん
04/12/09 01:38:48
>>244
URLﾘﾝｸ(www.google.com)

ほれ

246:デフォルトの名無しさん
04/12/09 01:47:22
>>245
「弱い型付け」で検索したら、Server Errorでますた(T-T)

247:デフォルトの名無しさん
04/12/09 01:53:30
>>246
釣りはいいからさっさと調べろボケ

248:デフォルトの名無しさん
04/12/09 01:53:33
型の指定が「無い」ことを「弱い型付け」と呼んでいいんですか？

249:デフォルトの名無しさん
04/12/09 01:54:12
>>247
ほんとに出たんだって。
GoogleのServer Error

250:デフォルトの名無しさん
04/12/09 01:58:01
ところで、Bean定義がコンパイル時に型解決できないのを、コンパイルとは別にBean定義の検証してもいいんじゃないの？っていう疑問は解決できませんでしたよ。

251:デフォルトの名無しさん
04/12/09 23:51:24
設定ファイルの不備が実行時でないと検出できないってのは効率が悪すぎる。
で、自分はこんな感じでAntを使用してチェックしてるんだが、どうよ？

1.spring-beans.dtdを利用して、DTDレベルの妥当性のチェックをする。
2./beans/bean/@classの値がクラス名として正しいのか検証する。

1.はAntのXMLValidateタスクを使用。
2.はXPath + java.net.URLClassLoaderを使用しAnt拡張タスクを自作して使用。

まぁ、DTDレベルの妥当性チェック + クラス名チェックなんで完全とまではいかないが、
実行時前にチェック出来るんで、だいぶ楽になった気がするな。

252:デフォルトの名無しさん
04/12/10 00:53:16
>>251
だから、とりあえず設定ファイル読み込むだけのプログラム作って、それでエラー検出してもらうんじゃだめなの？と。
なんならそれをAntのタスクにしてもいいし。

253:デフォルトの名無しさん
04/12/10 01:18:09
java房は世の中javaしかないと表ますね

254:デフォルトの名無しさん
04/12/10 02:31:46
別に普通にJUnitでテストしたらいいじゃん。

255:デフォルトの名無しさん
04/12/10 02:44:05
テスト至上主義は現実を考えるとどうかと思うよ。
毎回すべてをテストすることは難しいし。

256:デフォルトの名無しさん
04/12/10 23:44:01
>>255
ANTやMavenでプロジェクトに組み込んでしまえば
自動でやってくれるじゃん。

257:デフォルトの名無しさん
04/12/11 03:45:44
>>256
テストを自分で作らないかぎりは、自動でテストしてくれない。

258:デフォルトの名無しさん
04/12/11 10:02:07
そこでJTestですよ。

259:デフォルトの名無しさん
04/12/11 11:05:36
>>251
SpringIDEが、それぐらい、やってくれるんじゃないの。

260:デフォルトの名無しさん
04/12/11 11:39:36
コンパイラは誰でも必ず起動するってことだろ。テストはやらない人もいる。
というかやらない馬鹿もいるわけで。でも馬鹿でもコンパイルだけはする。

261:デフォルトの名無しさん
04/12/11 12:48:25
>>257
つまらんテスト仕様書を書く（しかもExcelで！）
よりテストコードを書くほうが楽しいと思わないか？

細かい修正のリリースの度に
テスト仕様書に則ってテストするのは
本来ならあたりまえの作業のはずなんだが
殆ど真面目に実行されていない。

テスト仕様書なんか納品前にでっち上げられる始末。
（銀行の勘定系とかはちゃんとやるけど）

それがmake（の相当品）に組み込まれているなら
便利だと思わないか？

262:デフォルトの名無しさん
04/12/11 14:05:56
>>261
> 細かい修正のリリースの度に
> テスト仕様書に則ってテストするのは
> 本来ならあたりまえの作業のはずなんだが
> 殆ど真面目に実行されていない。

細かいメソッド作成の度に
テストファーストに則ってテストを作成するのは
本来ならあたりまえの作業のはずなんだが
殆ど真面目に実行されていない。

というのと違いはあるのかな？

263:デフォルトの名無しさん
04/12/12 00:32:30
>>262
目視テストでは修正リリース時に毎回再実施のコストがかかる。
「真面目に実行」されていないのはリソース不足が理由。

自動テストでは上記の再実施のコストは激減する。
「真面目に実行」されないケースは開発者のスキル不足と
腐敗アーキテクチャが理由。

以上。

264:デフォルトの名無しさん
04/12/12 02:57:00
>>263
> 自動テストでは上記の再実施のコストは激減する。

再実施のコストが激減しても、テスト初回のコストは激増するわけだろ。

> 「真面目に実行」されないケースは開発者のスキル不足と
> 腐敗アーキテクチャが理由。

これが通常のテストに当てはまらない理由と

> 目視テストでは修正リリース時に毎回再実施のコストがかかる。
> 「真面目に実行」されていないのはリソース不足が理由。

これがテストファーストに当てはまらない理由を教えてもらいたい。

265:デフォルトの名無しさん
04/12/12 17:58:07
>>255
俺もそう思わんでも無いけど、そう思うのは自分の技能不足だということに気づいた今日この頃

266:デフォルトの名無しさん
04/12/12 17:59:42
JUnit in Action 嫁。

267:デフォルトの名無しさん
04/12/12 19:12:50
>>265
チーム全員、すべてのプロジェクトで徹底するのが難しいんだよ。

268:デフォルトの名無しさん
04/12/12 21:09:02
>>265
つまり、ユニットテストというのは、個人の能力に依存することになるんだよね。
で、ユニットテストに依存するということは、チームの個々人の能力に依存することになる。
安定して開発するための一般的な手法としては、テストファーストはお勧めできない。

269:デフォルトの名無しさん
04/12/13 00:10:47
そういうことを想定してたからこそ、ペアプロって発想が出てきたんだと予想してみる。

270:デフォルトの名無しさん
04/12/13 01:28:06
ペアプロって人月が倍になるように見えるんだけど間違ってる？
典型的な請負DQNシステムの場合、そういう余剰な工数ってどこから
捻出できるの？

271:デフォルトの名無しさん
04/12/13 01:49:37
XPの本で読んだだけだけど、研究によると、ペアプロをするとコーディング時間は
確かにのびるが、２倍の200%ではなくて、115%くらいになるそうだ。でその15%分、
品質が15%あがるらしい。どうやって計ったのかは知らない。

272:デフォルトの名無しさん
04/12/13 11:56:23
そうじゃなくて2人分の金が必要って話になるんじゃないかってことだろ。人月だから。

273:デフォルトの名無しさん
04/12/13 13:03:39
二人分の金が必要なのは当たり前だ。二人いるならね。どんな手法だろうが
二人いるなら二人分の金がかかる（奴隷でない限り）。

で二人で一緒に仕事すると、一人で別々にやる場合と比べて生産性が半分になりそうな
ので、費用も倍になりそうだという話じゃないか？
実際には別々にやった時と同じくらいの生産性を（つまり二人で二人分）を出す（らしい）と
いうことなんだが。
まあほんとかどうかは知らない。

274:デフォルトの名無しさん
04/12/13 13:20:16
問題は、プログラムには単純作業的なものが多くて、ペアプログラミングの効率のよさが得られるところが少ないってことじゃないのかな？
データベースからとってきた値をJSPに流し込むのって、ただの作業だし。

275:デフォルトの名無しさん
04/12/13 20:04:55
>>273
> で二人で一緒に仕事すると、一人で別々にやる場合と比べて生産性が半分になりそうな
> ので、費用も倍になりそうだという話じゃないか？
そうそう、そういいたかったんだ。ありがとう。

276:デフォルトの名無しさん
04/12/13 21:49:00
>>268
それはユニットテストだのＴＤＤだの以前に、
きちんとバグのないソフト作るとか、きちんとテストできるとか、きちんとデバッグできるだとか、
ある程度個人の能力に依存するのは当然だと思うぞ。
１００人の人間がいて、１００人とも皆が同じ答えを出すっていうのは人間じゃないぞ。

277:デフォルトの名無しさん
04/12/13 22:11:52
>>276
コンパイラでチェックできるのなら、100人の人間がいて、コンパイルに通っていれば、100人とも皆が書いたコードがチェックに通っている。

278:デフォルトの名無しさん
04/12/13 23:48:13
なんだかいつの間にかテストの有効性の話になってるが、もともとは、
コンパイラで型チェックさせるなんて意味あんのか、別の方法でチェックしても
いいじゃん、という話だったんじゃないか？

おれは>>260と同じ理由で価値があると思ってるけど。

279:デフォルトの名無しさん
04/12/25 14:58:37
今月のJavaWorldの記事でGeronimoの記事を読んでたんだけど
コア部分はDIコンテナなんだね。MBeanで定義した各サービスをDIコンテナを使って依存性注入したり
独自のサービスをMBean化して公開出来るようになるらしい
記事には書いてなかったけど、そのDIコンテナってSpringを使ってるそうだし
今後は、APサーバーがDIコンテナを核として構築されるのが主流になっていくのだろうか

280:デフォルトの名無しさん
04/12/26 00:04:13
俺様フレームワークを作るときにいつも困ってるのが「Factoryの提供の仕方」だったからな。
GBeanという形でFactoryを隠すことで、コンポーネントの利用者はサービスのみを享受できる。

サービスを提供したいのに、サービスを利用する準備から伝えないといけないのは、提供側も利用側もめんどくさい。
DIコンテナがあれば、提供者が好き勝手にFactoryを準備できる。
来年からやるプロジェクトではぜったいDIコンテナ使う。
S2よりはSpringだな。

281:デフォルトの名無しさん
04/12/26 00:18:57
>>279
内部がSpringって、あのAOPが自分のインスタンスメソッド呼び出しには適用されない問題は
大丈夫なのかな。（クラスＡのset.*にaspectを適用したら、最初に呼び出したsetHogeには
Aspectが適用されるけど、setHogeからthis.setHageを呼んだらAspectが適用されない問題）

実装の仕方みて「あーなるほどこりゃ自分で自分のメソッド呼んだら適用されないなー」と
思いはしたが、AOP的には困ったもんなのでまじなんとかしてほしい。

282:デフォルトの名無しさん
04/12/26 00:32:48
一番使われるトランザクションとかログてきには、あまり困らないのでなんとかしないんじゃない？
するかな？

283:デフォルトの名無しさん
04/12/26 00:40:09
おい、「setなんたらというのが呼ばれたら全部ログ吐け」ってのが、ちゃんと
動かない（ことがある）ってことわかってるか？

284:デフォルトの名無しさん
04/12/26 00:44:11
>>281
GeronimoはAOPは標準では提供しないらしいよ。コアに持っているのはあくまでDIコンテナで
AOPについては既存のものがGBean対応してくれるのを期待してるらしいね
AOPをコアに置いているJBossとは考え方が違うのかな？

285:デフォルトの名無しさん
04/12/26 01:32:44
>>283
でも、ログが重要なのって、オブジェクトの入り口のメソッドだから、急いで対応するほど問題になってないんじゃない？

286:デフォルトの名無しさん
05/01/06 01:32:25
proxyタイプのAOPじゃそれが限界だろ。いやならAspectJだ

287:デフォルトの名無しさん
05/02/15 01:33:40
Springしかり、最近のORMしかり、マッピングファイルうざい。
そんなさ、余計にバグ増やしてるようなもんじゃん。
補完も出来ないし面倒なだけだ。

288:デフォルトの名無しさん
05/02/15 01:57:26
まあマッピングファイルがうざいということには賛成だな。
DI Containerは便利だし使ってるけど、たしかにマッピングファイルを書くのがかなりうざい。
ある程度自動化できるとは言ってもなあ。

289:デフォルトの名無しさん
05/02/15 02:17:31
今のところだいたいXDocletで書いたもので用が足るから、あまり困ってない。
Strutsタグ+α程度で。

290:デフォルトの名無しさん
05/02/15 02:38:31
そもそも、何でもマッピングファイルにすれば保守性、拡張性に
優れるって発想は誰からのものなんだ？
増えすぎると逆効果だぞ・・・
ＪＡＶＡの世界って品質よりも名前だよな。著名な製作者が
提唱すると、何でもスタンダードになっちゃう。

次ページ