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

Java Spring Frameworkを語るスレ

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

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

語るべし。
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
0800デフォルトの名無しさん2006/07/04(火) 20:58:53
時給１０００円でＪａｖａ教えてくださるかたを募集します
場所　所沢（池袋・高田馬場から直通）
よろしくおねがいします
ｉ−ｗａｎｔ−ｔｏ−ｓｔｕｄｙ−ｊａｖａ＠ｈｏｔｍａｉｌ．ｃｏ．ｊｐ
（アドレスは全角で書いてあるので半角に直してください）
0801デフォルトの名無しさん2006/07/05(水) 03:49:26
コンビニのバイトより安いですが、よろしくお願いします。
0802デフォルトの名無しさん2006/07/05(水) 16:53:11
おひおひ、1,000\/h っていくら何でも安すぎだよ。
それじゃ労働しようとする意欲湧かねぇな。

君が♀なら別。
0803デフォルトの名無しさん2006/07/05(水) 17:12:10
javaを教えると一言に言っても色々あるしな
0804デフォルトの名無しさん2006/07/05(水) 19:13:48
Springと関係ないな
0805デフォルトの名無しさん2006/07/05(水) 19:33:12
>>804
つーかスレタイにJavaが含まれているスレに無差別絨毯爆撃しているだけだから無視するのがよろしいかと
0806デフォルトの名無しさん2006/07/05(水) 22:35:28
しかし以外にたくさんあるんだな。
>つーかスレタイにJavaが含まれているスレ
ブックマークしていながら、今回のマルチが出るまで気づかなかった。
0807デフォルトの名無しさん2006/07/07(金) 15:39:40
Spring WS のドキュメントが結構揃ってきたすね。
前は XML-Object Mapping の章しかなかったのに。
そろそろまじめに調べ始めるかな。
08088002006/07/17(月) 21:33:22
教える対象は超初心者です。

専門学校などでJavaを勉強されていて夏休みだけ教えたいという方も歓迎です
0809デフォルトの名無しさん2006/07/18(火) 12:06:26
javaの前に常識って物を勉強したほうが良いと思います^^;
08108002006/07/18(火) 12:49:11
常識も教えていただければと思います。
0811デフォルトの名無しさん2006/07/18(火) 14:19:48
ここで聞いても学べません
0812デフォルトの名無しさん2006/07/20(木) 22:25:56
もはや完全にSeasarに押されてるな。
0813デフォルトの名無しさん2006/07/21(金) 00:57:25
>>812
獄長乙
0814デフォルトの名無しさん2006/07/21(金) 23:57:04
WebMVCのSimpleFormControllerで、
フォームのパラメータ名とCommandのフィールド名を
任意にマッピング（バインド）する方法がわからない…
0815デフォルトの名無しさん2006/07/24(月) 17:54:58
spring:bind使ってないの？
0816デフォルトの名無しさん2006/07/26(水) 12:31:58
Java World 2006/09 特集

2.0 とか関係なしに
・EJB3.0 に懐疑的
・ORM は最終的に JDBC に回帰する
な姿勢が良かった。

あと Acegi の記事が後で役に立ちそう。
0817デフォルトの名無しさん2006/08/01(火) 13:18:00
漏れJavaWorld斜め読みした所。詳しくはこれから読む。

豆蔵が書いたのねコレ。漏れは以前、長谷川ダンナの話を
聞いたことがあるのだが、

「Hibernateは確かに優れたプロダクトだが万能じゃない。
　陥りやすい穴もあるから慎重に検討してから導入した方がいい。」

って言ってた。禿同だったんだけどね。今回の記事もその思想が
根底に流れているみたいだね。

JPAマンセーな流れの中でこういう視点は貴重だと思う。
0818デフォルトの名無しさん2006/08/09(水) 01:22:18
Servlet依存のコード(JSFバッキングBeanも含む)とサービスメソッド
のデータ受け渡しってPOJOでもDTO使った方がいいのかな？
直にビジネスオブジェクト受け取った方がコーディングが楽なんだが・・・
0819デフォルトの名無しさん2006/08/10(木) 09:35:55
>>818

http://www.atmarkit.co.jp/fjava/kaisetsu/j2eewatch02/j2eewatch02.html
から抜粋

このように、POJOをそのままEntity Beanとして扱うことができれば、従来のEJB開発で
Web層とのデータ交換に利用されてきたDTO（Data Transfer Object）パターンはもはや
不要となる（実のところ、J2EEパターンの多くはEJBの使いにくさを緩和するために
生み出されたアンチパターンであるという見方もある）。
0820デフォルトの名無しさん2006/08/15(火) 22:23:19
うーん、結局、「Web層」って、BCE でいうと、どこになるんだろか。
「Web層」がBだけの役割であれば、M に B を依存させないために、
DTO(のようなもの)は必要のような気がする。

表示で使うPOJOを直接永続化するということは、
逆に永続化の都合に（N:N関係は扱えないとか）、
表示部のロジックが依存してしまう、ということになるんじゃないの？
0821デフォルトの名無しさん2006/08/16(水) 10:13:12
この本の書評たのむ。

http://www.amazon.co.jp/gp/product/4797334223/

特にオレが知りたいのは、

・2.0を紹介してるか。

・JPAを使ったWebApp例で、マンセー記事ばかりではなく
　注意点やアンチパターン的な解説もしているのか。

・SpringWebServiceの解説あるのか。

・SpringRichClientとかAcegi(SpringSecurity）の解説あるのか。

でも、読んだ印象でも何でもいいから知りたい。
0822デフォルトの名無しさん2006/08/17(木) 11:01:55
>820
> 表示で使うPOJOを直接永続化するということは、
> 逆に永続化の都合に（N:N関係は扱えないとか）、
> 表示部のロジックが依存してしまう、ということになるんじゃないの？
シンプルなアプリなら問題ないと思うんだが。
ただ、発想としては「永続化するPOJOを直接表示する」が正しいかと。

どうしても気になるなら、
サービス層で永続化用DTOからプレゼン用DTOへ変換してやれば良いと思う。(higaﾀｿのシンドメインモデルってやつね)
問題は、プレゼン用DTO・変換ロジックを実装するコストに対して価値があるかどうか。では？
08238222006/08/17(木) 17:21:40
間違い。
×　シンドメインモデルってやつね
○　Dxoってやつね

あと
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?LocalDTO
0824デフォルトの名無しさん2006/08/22(火) 09:50:14
貼っとく

【IBM】Introduction to Spring 2 and JPA
https://www6.software.ibm.com/developerworks/education/j-spring2/
0825デフォルトの名無しさん2006/08/25(金) 23:20:47
tp://www.sssg.org/jp-springframework/?FAQ
Seasarの連中もキモイけどこれもイタイ。
0826デフォルトの名無しさん2006/08/25(金) 23:23:36
>>824
ログインパスワード教えて
0827デフォルトの名無しさん2006/08/26(土) 09:06:37
>>825
ゆるされるはんいじゃない？
■ このスレッドは過去ログ倉庫に格納されています