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

Java Spring Frameworkを語るスレ

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
http://www.springframework.org/

乱立するフレームワークと競合するプロトコルの嵐のなかで、
リスクの高い決断を余儀なくされているJavaデベロッパ、プ
ロジェクトマネージャに対する福音です。

語るべし。
0699デフォルトの名無しさん2006/03/09(木) 01:38:51
クライアント側でリソース名を明示的に書いているから
DIとはいいがたいと思ってます。

＞"ただのlookup"ではないしな。
どんな嬉しさがあるか、教えていただけないでしょうか。
煩雑な記述が減る程度しか思いつきません。

＞interfaceがメソッドに付けれますか、と。
@Stateful はメソッドに付かないと思うけど。
0700デフォルトの名無しさん2006/03/09(木) 03:37:13
>>699
> クライアント側でリソース名を明示的に書いているからDIとはいいがたいと思ってます。

つまり、DIをわかってないと。
0701デフォルトの名無しさん2006/03/09(木) 13:01:15
そっか。DIの定義が変わったのか。
0702デフォルトの名無しさん2006/03/09(木) 22:20:05
>>701
変ってないだろ。
君が勘違いしてるだけ。
0703デフォルトの名無しさん2006/03/11(土) 15:16:19
2.0になってどう？
近い将来でseasar使うか2.0使うか迷ってるんだが、
Spring側の利点が見つからない・・・

両方つかってみたけど、seasarだとXMLをかなり省けるから
楽なんだが・・・

誰か意見ください。
0704デフォルトの名無しさん2006/03/13(月) 13:14:45
>702
DIって、クライアント側で明示的にリソース指定した部分が
コンテナが注入するようになって素敵だよって流れだと思ってたんですが。
で、勘違いのない本当の定義とは？

>703
利点が見つからないならSeaser2使えば良いかと。
とりあえずXMLが省けることは多分大した利点にならんよ。
0705デフォルトの名無しさん2006/03/13(月) 21:56:40
横槍ｽﾏｿ

>>704
そもそもEJB3のDIは「明示的にリソース指定」はしないぞ

＞とりあえずXMLが省けることは多分大した利点にならんよ。
その根拠は？
書かなくて済むのであれば書かないに越したことは無いし
XMLのメンテナンスだって馬鹿にならない
0706デフォルトの名無しさん2006/03/13(月) 23:15:36
>>704
DIの最低限の定義は、自分でインスタンスをとって来ないで、よそから注入してもらうこと。

@EJBアノテーションつけたとしても、それなりのコンテナ使わない限りなにも影響はない。
そのままSpringやSeasar使えばそれなりに注入される。
0707デフォルトの名無しさん2006/03/14(火) 10:32:53
DIに関して705氏と706氏の意見で納得。
確かに自分でインスタンスとってきてるわけではないね。
俺はとってくる情報が書かれてることそのものが嫌いなんですが
これはDIとは関係ないってことですね。

>その根拠は？
autowire 使えばそれなりに記述量は減るけれども
曖昧さが増えてかえって混乱を招くだけだった、との経験から。
Seasar2だと違うのかも知れない。
適当なこと言ってごめんなさい。

それにしても盛り上がらないスレですね。なんでだろ。
0708デフォルトの名無しさん2006/03/14(火) 18:46:23
一部雑誌や新しいもの好きが飛びついてるだけで
現場ではほとんど使われてないから。
0709デフォルトの名無しさん2006/03/14(火) 19:36:29
はい、飛びつきました
0710デフォルトの名無しさん2006/03/14(火) 22:14:33
うちでは全部SpringかSeasar使ってるが、世間ではそうなのか？
トランザクションに関してはとても楽だが
0711デフォルトの名無しさん2006/03/15(水) 17:34:47
>>707
いったん使い出せば、通常の範囲では質問もなにもないし、特に話題がないからかもね。
0712デフォルトの名無しさん2006/03/15(水) 17:52:50
ｲｲﾅｰ
うちで使ってるｽｹﾞｰ高いアプリケーションサーバーは
jspしか使えない
0713デフォルトの名無しさん2006/03/15(水) 21:47:24
そりゃないんじゃね〜の？
0714デフォルトの名無しさん2006/03/15(水) 22:14:35
>>712
BroadVision One-To-One
以前はC++しか使えなかった。マジで。
0715デフォルトの名無しさん2006/03/15(水) 22:14:55
713宛てだった
0716デフォルトの名無しさん2006/03/15(水) 22:30:54
「Portal,Commerceの価格は1CPUで810万円からとなっております。」
ΣΣ（ﾟдﾟlll）
0717デフォルトの名無しさん2006/03/16(木) 00:03:31
そういやあ、WebObjectsも昔は７５０万とかしたよなあ。。。。
0718デフォルトの名無しさん2006/03/16(木) 00:05:24
製品カタログ見ても何をするものなのかが分からん。
0719デフォルトの名無しさん2006/03/16(木) 02:13:23
JSPしか動かないTomcatみたいなの
ショボいDBのラッパーとかユーザー管理とかビジネスルールのライブラリとかがいっぱい付いてる
あと やたら高い
0720デフォルトの名無しさん2006/03/16(木) 03:57:55
うちの会社で出してるゴミコンポーネントも945万円するお。
1年で1個売れれば万々歳だって。
0721デフォルトの名無しさん2006/03/17(金) 16:09:08
そりゃむしろ、945万もするから売れるんだろう。
金を出す人間は、無料でしっかりしたモノを嫌がって
バカ高くてヘボいモノを好む傾向にあるから。

で、現場は地獄を見る、と。
0722デフォルトの名無しさん2006/03/17(金) 17:20:41
無料だとちょっと問題が出るとすぐ捨てるけど、
金かけてると捨てるわけにはいかないからなあ
0723http://www.vector.co.jp/soft/win95/util/se072729.html2006/03/18(土) 20:26:19
TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
0724デフォルトの名無しさん2006/03/25(土) 12:11:47
なあ、参照しかしないクエリーでもトランザクション切ってる
なんて事ないよな？
サービスのインスタンス化時にトランザクション切るのをデフォルト
にしてるのを見たことあるぞ。。。
同時アクセス数増えたとき、大変な事になるのがわからんのじゃろうか。
0725デフォルトの名無しさん2006/03/27(月) 10:58:31
AOPでトランザクション管理するなら、
READだけの処理では普通は開かんようにするはず。
0726デフォルトの名無しさん2006/03/27(月) 14:11:08
>AOPでトランザクション管理するなら
してなかったりして
0727デフォルトの名無しさん2006/03/27(月) 16:22:43
貼っとく

【BEA】Using the Java Persistence API with Spring 2.0
http://dev2dev.bea.com/pub/a/2006/03/jpa-spring-medrec.html
0728デフォルトの名無しさん2006/03/27(月) 19:02:56
>>724
どうして大変な事になるの？
0729デフォルトの名無しさん2006/03/28(火) 09:58:12
複数のテーブルを参照してひとつのデータを作るような場合は、
読み込みでもトランザクションきらないとまずいんじゃないの？
0730デフォルトの名無しさん2006/03/28(火) 10:11:35
>>729
> 複数のテーブルを参照してひとつのデータを作るような場合は、
JOINではなくて、複数のSELECT発行って事？
0731デフォルトの名無しさん2006/03/28(火) 11:05:09
>>730
ISOLATION_LEVELのデフォルトって普通はREAD_COMMITTEDじゃないの？
複数のSELECTまで考えるとISOLATION_LEVELをREPEATABLE_READに変更しないと駄目じゃない？
0732デフォルトの名無しさん2006/03/28(火) 11:33:17
>>731
InnoDBのデフォルトはREPEATABLE_READみたいだなあ
07337302006/03/28(火) 11:45:37
>>731
>>732
DBベンダによってデフォルトが異なる。んで、大抵はREPEATABLE_READ(らしい)。

結論としては、複数のSELECTを発行するサービスのメソッドは
トランザクション制御しなきゃならんって事か。
07347312006/03/28(火) 11:59:04
>>732
Oracleのデフォルトは文レベルの読み取り一貫性(READ_COMMITTED)だったような...

>>733
>結論としては、複数のSELECTを発行するサービスのメソッドは
>トランザクション制御しなきゃならんって事か。

加えて以下の様に明示的にISOLATIONレベルを指定しないといけないのかな？
<property name="transactionAttributes">
<props>
<prop key="get*">PROPAGATION_REQUIRED, ISOLATION_REPEATABLE_READ, readOnly</prop>
</props>
</property>
0735733(=730)2006/03/28(火) 12:24:32
>>734
いささか古いが、
http://www.tomlauren.com/weblog/archives/000019.html
によると、OracleのデフォルトはREAD_COMMITTEDみたいだ。
でも、REPEATABLE_READがNotSupportって事になると、
SERIALIZABLEしかないな。

最新の公式資料キボン。
07367312006/03/28(火) 14:16:43
>>735
Oracleで以下の操作をやると
conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);

java.sql.SQLException:
READ_COMMITTEDおよびSERIALIZABLEのみが有効なトランザクション・レベルです。
...
ってエラーが出るよ。

Oracleだと更新処理を伴うトランザクションでトランザクションレベルの読み取り一貫性を
保証したいのであればSERIALIZABLEを指定するしかないのでは？
※更新処理を伴わないのであればreadOnlyだけで大丈夫みたい

でも実際にSERIALIZABLEがどうしても必要になる局面があんまり無いような気も...

で、元の話は

>>724
> なあ、参照しかしないクエリーでもトランザクション切ってる
> なんて事ないよな？

ってことだけどこれって

読み取り一貫性を保証しなくて良い参照のみのトランザクションでAOPで管理せず、AutoCommitも無効にしている場合、
明示的にトランザクションを開始する必要があるのか？

という意味なのかな？
0737デフォルトの名無しさん2006/03/28(火) 16:19:46
Strutsを使った場合の、AOPによる宣言的トランザクション管理について意見を聞かせてください。

(前提)
・サービスクラスの各メソッドはAOPによって宣言的トランザクション管理されている。
(処理)
・リクエスト->更新Action->表示Action->JSPとディスパッチする。
・更新Actionと表示ActionはサービスクラスのupdateHoge()やfindHoge()を呼び出す。

これだと、1回のリクエスト中に2つのActionが2回ビジネスロジックを実行するから、
トランザクションも2回発生してしまいますよね？(1操作=2トランザクション)

何となく腑に落ちませんが、これが当たり前なんでしょうか？

それとも、Facadeサービスから更新も検索もまとめて呼ぶべきでしょうか？
更新と検索の引数リストが全く異なる場合はFacadeしたくないんですが…
0738デフォルトの名無しさん2006/03/28(火) 20:03:23
好きにしろとしか……
個人的には、更新作業の頻度次第で決める
0739デフォルトの名無しさん2006/03/29(水) 11:26:28
本家よりコピペ

Spring 2.0 Release Party in Stuttgart (organized by JUGS)
Submitted by Juergen Hoeller on Fri, 2006-02-24 18:31. Event
Start: 2006-03-30 14:00
End: 2006-03-30 23:00
Timezone: -14400

いよいよ2.0が間もなく到来だぬ。

ところで2.0の目玉って何なのさ？（恥）
0740デフォルトの名無しさん2006/03/29(水) 16:35:27
>>738
んじゃ、Action2つにする。

とりあえず、HibernateでOpenSessionInViewしておけばAction2つでも
1トランザクションになるよね？
0741デフォルトの名無しさん2006/03/31(金) 23:11:17
>>740
トランザクションとHibernateのセッションの区別はついてますか？
0742デフォルトの名無しさん2006/03/32(土) 00:26:43
これ、掻い摘んでいうと何？
0743デフォルトの名無しさん2006/03/32(土) 01:38:39
軽量コンテナ
0744デフォルトの名無しさん2006/03/32(土) 05:59:35
>>742
「Java2EEなんかクソくらえ」
0745デフォルトの名無しさん2006/03/32(土) 06:03:37
今日は32日だ。うそをついていい日ではない。
0746デフォルトの名無しさん2006/03/32(土) 10:39:20
http://www.2ch.net/
＊エイプリルフール中止のお知らせ＊
本年度、ITバブル崩壊の余波、またライブドア事件の混迷、楽天ゴールデンイーグルスぶっちぎり最下位など、
悪条件の重なりによる株価低迷が２ちゃんねる運営費にも多大なる影響を与え、
火の車である今の財務状況を鑑みるに、エイプリルフールの全面中止もやむなしという判断にあいなりました。
ご期待されていた皆様には大変申し訳ありませんが、どうぞよろしくご理解いただければ幸いです。
また、妄言民族と呼ばれ、近隣アジア諸国に多大なる苦痛を与えている日本国民としてこれを良い機会と考え、
例えエイプリルフールだとしても嘘を無くし、世界平和に貢献できる公明正大な言論の場を標榜すべく襟を正しつつ、
２ちゃんねるはエイプリルフールの根絶に今後とも邁進していく所存でございます。
07477242006/04/02(日) 12:30:05
>読み取り一貫性を保証しなくて良い参照のみのトランザクションでAOPで管理せず、
>AutoCommitも無効にしている場合、明示的にトランザクションを開始する必要があるのか？
そうじゃ。RDBにもよるが、読み取り一貫性を実現するために、大体がテンポラリ領域に
データをコピーしている（OracleとSQL Serverは少なくともそう）。
この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。
（同時アクセスが多いと、Tempがクリアされる前に次が来ちゃうからじゃ）
このエラーを受けてDB屋にTemp領域増やせっていうのはナンセンス。
もちろん、ビジネスロジック上大きなTempが必要な場合もあるからそれは、
ちゃんと見積もりをDB屋に伝えればいい。大きくするのに否定的な訳じゃなく
PGの手抜きに対して文句を言ってるんじゃ。

また、上記の事だけじゃないが、上記だけからでも結構コスト（負荷）
が掛かることは言うまでもないよな。
0748デフォルトの名無しさん2006/04/02(日) 13:10:03
>>747
> そうじゃ。RDBにもよるが、読み取り一貫性を実現するために、大体がテンポラリ領域に
> データをコピーしている（OracleとSQL Serverは少なくともそう）。

オラクルは違うだろ。
データがコピーされるのは読み取り時じゃなくて更新時。
コピー先はテンポラリじゃなくてUNDO表領域。

> この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。

頻繁に閲覧されてもそれだけじゃエラーにならない。
頻繁に更新されている時にのんびり読んでるとORA-01555
本当に理解して書いてるか？
0749デフォルトの名無しさん2006/04/02(日) 15:04:58
> > この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。
>
> 頻繁に閲覧されてもそれだけじゃエラーにならない。
> 頻繁に更新されている時にのんびり読んでるとORA-01555
> 本当に理解して書いてるか？

激しく同意。
付け加えるなら、Oracleではトランザクションの有無にかかわらず
文レベルの一貫性は常に保証しようとするから、
> 頻繁に更新されている時にのんびり読んでるとORA-01555
という状況はトランザクションの有無にかかわらず起こりうる。

だから、>747の主張は少なくともOracleには当てはまらない。
07507402006/04/02(日) 18:58:45
>>741
スマソ＆サンクス
考えてみれば、サービス層でAOPトランザクション管理していると、
複数Actionが複数サービス呼び出す時点で複数トランザクションになる…
んでOpenSesseionInViewしてもHibernateのSessionが1つに保たれるだけですな。

結論すると、2Actionだと2トランザクションでいくしかないのか。
07517312006/04/03(月) 14:34:04
あんまりSpringと関係が無くなって来たような気が...

>>747
>>748
>>749
読み取り一貫性に関しての詳細は置いておいて元の話だとOracleでは
以下になるんじゃないかな？

必要な読み取り一貫性が文をまたがるのであれば読み取り専用の
トランザクションを明示的に開始する必要がある。

必要な読み取り一貫性が文レベルでよいのであれば明示的にトランザクションを
開始しなくても良い(コネクションを生成した際のトランザクションがずっと使われている)
但し、更新処理の前にはCommitを発行して明示的にトランザクションを開始する必要がある

どちらにしてもOracleで更新やロックを伴わないトランザクションでCommitを行っても
無視される(v$sesstatのuser_commitは増えない)のでパフォーマンスには大した影響を与えない

結局のところ空コミット(参照のみトランザクションでのコミット)のコストの話なのかな？
07527402006/04/07(金) 20:14:03
今さらだが、ようやくStruts+Spring+Hibernate
(DelegatingActionProxy、
StandardXAPoolDataSource、
JOTM、
OpenSessionInViewFilter、
JtaTransactionManager)
のアプリが作れたよ…

さて、次はSeasarも試してみるか…
0753デフォルトの名無しさん2006/04/07(金) 23:51:41
Hibernateって使える？
0754デフォルトの名無しさん2006/04/08(土) 06:37:50
Java標準になったくらい使える。
0755デフォルトの名無しさん2006/04/08(土) 13:40:24
DB設計がしっかりしているならHibernate
DB設計が腐っているならiBATIS
どっちも便利であるのは間違いない。
適材適所で。
0756デフォルトの名無しさん2006/04/27(木) 06:56:47
spring 使いたい。しかしEJBコンテナを捨てるには問題が。
リモート呼び出しやORM（hibernateで）は置き換えることが
できたけど、EJBのMessage Driven Beanを代替するものが
見つからない。MDB便利すぎる。
0757デフォルトの名無しさん2006/04/28(金) 01:17:20
Struts+Springで
SpringのViewクラスを使用したい場合は
どうすれば良い？
0758デフォルトの名無しさん2006/04/28(金) 21:03:44
それってStruts使う意味あんの?
0759デフォルトの名無しさん2006/04/29(土) 20:34:44
>>757
既存システムとしてStrutsの部品があって
ExcelとかPDFを出力したいので
SpringのViewを使用する
0760デフォルトの名無しさん2006/04/29(土) 20:36:33
つ POI
0761デフォルトの名無しさん2006/05/08(月) 16:21:07
Struts(SpringのStrutsインテグレーション機能)とSpringMVCって同時に動作できないの？
web.xmlとXXX-servlet.xmlを調整すれば、実現できそうだけど？
0762デフォルトの名無しさん2006/05/09(火) 09:52:00
1.2.8記念

って何なのこれ？
0763デフォルトの名無しさん2006/05/10(水) 18:31:22
1.2.8 についてか、Spring についてか。＞何なの
0764デフォルトの名無しさん2006/05/11(木) 00:10:50
クラス属性に対応するbean定義の<property name>の値って、何でもいいんだな。
setterの名前さえ整合性が取れていれば。
0765デフォルトの名無しさん2006/05/19(金) 09:53:31
貼っとく

Rodが語った2.0@JavaOne

https://www28.cplan.com/cb_export/PS_TS-3744_277744_124-1_FIN_v2.pdf

user:contentbuilder
pass:doc789
0766デフォルトの名無しさん2006/05/19(金) 14:31:03
>765
thx.

Message-Driven POJO なんて構想もあったのか。初めて知った。

Extensible XML Confinguration は
俺様設定が乱立しそうでちと怖いな。
0767デフォルトの名無しさん2006/05/19(金) 14:32:45
>>761
そりゃできるだろ。
0768デフォルトの名無しさん2006/05/19(金) 16:50:26
では757は解決だな
0769デフォルトの名無しさん2006/05/20(土) 00:21:20
ソースコード上でAppicationContextを利用してBeanを取得するしかない
場合、どうしてます？
いい方法を考えているうちにgetBean("BeanId")のコードがいっぱいできた
まんまプロジェクト終盤にきてしまった。。。
0770デフォルトの名無しさん2006/05/20(土) 00:56:56
そんなに気にしなくていいと思うけど、
getBeanId()のメソッドを用意して静的にアクセスできるようにはしてる。
0771デフォルトの名無しさん2006/05/20(土) 00:59:34
もちろんID取得もSpringで管理するんだよな?
0772デフォルトの名無しさん2006/05/20(土) 01:01:22
そもそも、自分でgetBeanしなくていいように作ります。
StrutsならDelegatingActionProxy使えばいいし
TapestryもSpringと連携させてコンポーネントにInjectしてもらえるし。
0773デフォルトの名無しさん2006/05/20(土) 06:12:45
それができない場合はルックアップするしかない。
どこからでもルックアップできてしまうので収集がつかなくなるおそれはあるけど、
>>770 のように bean の種類ごとにルックアップするメソッドを用意しておけば
いく分見通しもよくなると思われ。
0774デフォルトの名無しさん2006/05/20(土) 08:56:55
それただのサービスロケータになってる
別にいいけど
0775デフォルトの名無しさん2006/05/20(土) 12:58:25
サービスロケータだと何がダメなの?
0776デフォルトの名無しさん2006/05/20(土) 13:05:37
DI自体がサービスロケータ
0777デフォルトの名無しさん2006/05/20(土) 15:56:24
>>775
サービスロケータに依存してしまうからですよ。
0778デフォルトの名無しさん2006/05/20(土) 15:59:55
ただ、サービスロケータはコンパイルエラーでミスを検地できるので
単純にどっちが上とかはいえない

ってDIってネーミングつけた人いってなかったっけ？
07797752006/05/20(土) 16:13:32
>>777
なるほどー。ありがとうございます。
となるとそれくらいの依存は気にならないなー。
元レスは注入できない場合の話だし
07807692006/05/20(土) 16:55:15
かといって他の解決方法もないのですよね。たぶん。
ドメインモデルとは相性が悪いのでしょうか。やはり。
いまさら設計をトランザクションスクリプトにできないし。。。
まっ宣言的トランザクションだけでもかなり有効であることには
変わりないわけだし。
0781デフォルトの名無しさん2006/05/20(土) 22:52:38
＞ソースコード上でAppicationContextを利用してBeanを取得するしかない
場合

ってどういう場合なんだろう？
素朴な疑問。
0782デフォルトの名無しさん2006/05/21(日) 03:47:30
私が使っているフレームワークにはイベントリスナを登録しておくと
コールバックしてくれるという機能があるけど
イベントリスナには依存性注入のチャンスがないのでApplicationContextを使う。
0783デフォルトの名無しさん2006/05/21(日) 07:33:25
>>782
ここで解説されているみたいなことをやるべし
http://www-128.ibm.com/developerworks/edu/j-dw-java-springswing-i.html
07847822006/05/22(月) 00:01:56
>>783
自分でインスタンスを生成する必要がある場合の話です。

07857692006/05/22(月) 15:49:50
getBeanを利用する主な場面とは。。。
たとえば親子関係をなすドメイン（請求書と請求明細）などは
ロジック上で画面の内容をドメインに変換する必要があるのですが
明細クラスのような１クラスで複数インスタンス必要になる場合は
betBeanで必要数分インスタンスを生成する必要がある。
みたいな場面です。
0786デフォルトの名無しさん2006/05/22(月) 16:54:00
>>785
内部でインスタンスを生成する必要があるロジックの場合は、
そのインスタンスを生成するFactoryクラスをインジェクトする
ってのをよくやる。
0787デフォルトの名無しさん2006/05/23(火) 22:20:49
てかドメインモデルとはめちゃ相性悪い。
アナパタ時代の設計にDI使おうとすると死ねる
0788デフォルトの名無しさん2006/05/24(水) 11:41:00
よくわからんが、
higaﾀｿが提唱しているシンドメインモデルならドメインロジックだけDIにして、ドメインモデル(データ)
だけ通常の手段(new)で生成すればよいのでは？
ttp://d.hatena.ne.jp/higayasuo/searchdiary?of=5&word=%2a%5bgoya%5d
0789デフォルトの名無しさん2006/05/24(水) 13:07:20
▽どっちが速いSeasar2 VS Spring
http://cm.thinkit.co.jp/?4_23934_12965_1
0790デフォルトの名無しさん2006/05/24(水) 14:00:57
>>788
オレもそうしてる。ドメインのPOJOは自分でnewする方がOOしてる気分になるね。
DIに生成させるのはServiceLayer〜DataStoreLayerのドメイン『操作』クラス達だぬ。

>>789
ｷｬﾊｷｬﾊ。なんかヒガﾀｿ最近人格が変わった？ JavaOneでイジメでもくらったのかな。

PowerdBySpringのフレームワークがこんなにポコポコ誕生している現状を見れば、
1.2.xとスピード競争やった所で焼け石に水ﾀﾞﾇ。
AspectJが推奨スタイルになる2.0のこと知らぬ訳ではないだろうにね。

別にRodファンではないけどさ。
0791デフォルトの名無しさん2006/05/24(水) 15:39:44
785が考えるケースで getBean() することはない。
データは普通に new したらいい。
なんで getBean() しようとしたのか教えてくれ。
メリットが何一つ思い浮かばない。
07927882006/05/24(水) 17:02:50
>データは普通に new したらいい。
激しく同意。

ビジネスロジック周りでDIしたいと思うなら、
ドメインビジネスとしてクラスを切り分ければいいのでは？と思った次第。
07937692006/05/24(水) 22:06:40
>シンドメインモデル

>ドメインビジネスとしてクラスを切り分ければ。。。

ということは、私の思うトランザクションスクリプト + DAOという
組み合わせがDIでは有効という考えと同意と考えられます。
そちらのほうが合っているという結論ですよね。結局は。
DIを利用する上では状態をもつドメインはミスマッチであるということですね。
07947692006/05/24(水) 22:24:03
>なんで getBean() しようとしたのか教えてくれ。
>メリットが何一つ思い浮かばない。

785であげた例も悪かったですが。。。
1.getBeanするドメインが他のドメインを持っている。
オブジェクトグラフの一気取りが可能（Factory作ればすむという話もあるが）
2.やはりInterfaceを実装する実クラスをコードに書かなくてよい
この２つはかなりのメリットです。

もちろん前提がドメインロジックとデータの分離であれば、データに対して
getBeanするメリットが何もないというのは理解できますが。

DIを利用する上では状態をもつドメインはミスマッチである
けれども
上記の理由があるためドメインモデルでもDIを採用しました。
けれども
getBeanする部分をもっといいやり方はないですかねーという質問でした。
0795デフォルトの名無しさん2006/05/25(木) 01:09:09
Hibernate等のORマッパでドメインモデルを取得すれば、
one-to-manyなんかの関係は勝手に構築してくれる。
1の芋づる式にとりたいというだけでgetBeanするのはDIの役割とは違う希ガス。
（もしかして、DAOが生成するデータが≠ドメインモデルな設計？）

>2.やはりInterfaceを実装する実クラスをコードに書かなくてよい
はちょっと意味が理解できん。ｽﾏｿ。解説ｷﾎﾞﾝ。

>DIを利用する上では状態をもつドメインはミスマッチである
と
>上記の理由があるためドメインモデルでもDIを採用しました。
は納得できないなぁ。
そう考えた理由は？

あと、ビジネスロジックを切り出しただけでトランザクションスクリプトって呼ぶの？
SQLで記述するのか、呼び出し側の言語で記述するのか、が
ドメインモデルとトランザクションスクリプトの最大の相違だと思ってた。
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL
0796デフォルトの名無しさん2006/05/25(木) 01:14:00
うーん、ドメインモデルとかDIとかいろいろいじった結果一時DIに傾倒したが....

結局ところ、ドメインモデルのサポートとしてDIを使うくらいにしておきたいと
思った。
もしどうしてもどっちかを取らなくちゃいけなくなったら、サービス層を内製しても
ステートフルなドメインモデルを選択したい。Hibernateとか使うと、リッチなJava
オブジェクトをそのままＤＢにマッピングできたりするし。

それに、そっちのほうがオブジェクト指向っぽい感じがするから。
0797デフォルトの名無しさん2006/05/25(木) 15:57:44
精読したが
＞ 上記の理由があるためドメインモデルでもDIを採用しました。
の結論に至った理由が理解できなかった。

実際何を getBean() したのかが分からない。
getBean(リテラル文字) まくりな状況より
new した方が可読性高いし変なキャストもせずに済む。
設定ファイルで singleton="false" を書き忘れる心配もない。
どうしても生成部分を隠したいなら、
簡単な Factory を作って、そいつを DI でセットしたらいい。
0798デフォルトの名無しさん2006/06/29(木) 07:36:24
RC2あげ
0799デフォルトの名無しさん2006/07/04(火) 09:35:38
過疎スレ保全

つか、2.0期待sage
■ このスレッドは過去ログ倉庫に格納されています