【DI】Java Spring Framewoｒｋを語るスレ 2.0

【DI】Java Spring Fr ..

655:デフォルトの名無しさん
08/04/01 10:59:21
URLﾘﾝｸ(cubby.seasar.org) がSpringで使えるようになったらうれしい。

656:デフォルトの名無しさん
08/04/01 12:35:26
>>655
SAStrutsの方ならSpringで使えるようになる
URLﾘﾝｸ(d.hatena.ne.jp)
> SAStrutsとS2JDBCもSuper Agile Spring上に移植する予定です。

657:デフォルトの名無しさん
08/04/01 15:50:20
>>654

POJOのパラメータありメソッドをサクサク呼び出せるのがVelocityの良いところ。
JSPでもFunctionとかあるけど、staticメソッドのみなうえにtdl書くのが死ぬほど面倒くさい・・・
ツールはEclipse+VelocityWebEditでコード補完もバッチリできるよ。

>>653

自分も数年間JSP⇔Velocity両方使って試行錯誤してたけど、
SpringとかDIとの相性がいいからVelocityに落ち着いた。

658:デフォルトの名無しさん
08/04/01 17:18:32
>>657
velocityだとデザイナとの分離が不可能
分離しないタイプならJSPのほうが融通が利く

テンプレートとしては好きだけどね

659:デフォルトの名無しさん
08/04/01 22:29:08
>>656
4/1だもんな。
それに、Strutsはいらない。

660:デフォルトの名無しさん
08/04/01 23:35:09
>DIとの相性がいいから
DI云々よりも目的がハッキリしてるから好き。
どうせテンプレート機能しか使わないんだから
(タグ作り始めるとコードの暗号化を進めるだけ)
そっちに特化してる方が何かとシンプルでやりやすかった。

JSP のコンセプトがどれだけボヤけてたかは
その後に JSTL + EL を取り込んだことで自明でしょ。
最初からそれやっとけよって話。

661:デフォルトの名無しさん
08/04/01 23:50:35
コンセプトというか、単にASPやPHPの対抗馬として作っただけだしな

662:デフォルトの名無しさん
08/04/02 02:46:05
>>660

たしかにカスタムタグ自前で作り始めるとわけわかんなくなる…

JSPはスクリプトレットベースだったのを無理やりJSTL+ELを加えて
あげくにスクリプトレットレス推奨になってる時点でスコープやらなにやらグチャグチャになってると思う。

>>658
デザイナとの分離ならむしろ圧倒的にVelocity有利では？？

663:デフォルトの名無しさん
08/04/02 02:48:09
#foreach や#parse がデフォルトで無限ループができないようになってたり、
デザイナとの分業は余計な問題が起こらないようにいろいろ考えられてるよ。

664:デフォルトの名無しさん
08/04/02 03:11:31
FreeMarker はどうよ？

View 層に jsp より Velocity というのは自分も同意だが、
SpringMVC は、作らなければならないクラスが多い気がしてあまり好きじゃない。
なんつーか冗長というかめんどくさい。
おれがわかってないだけかもしれないけど。

665:デフォルトの名無しさん
08/04/02 03:55:11
>>662
デザイナは通常DreamWeaverとかつかうからjspはhtmlと同じように扱えるんだよ
しかもtomcat連携も可能で動的htmlを表示したままcss設定できたりな

666:デフォルトの名無しさん
08/04/02 04:10:36
>>664

SpringMVCはなんかクラス名がピンとこないのが多い・・・
Model、View、CommandとかMVCでいうと実際にはController部分（？）なのに
紛らわしい感じで混乱する。

667:デフォルトの名無しさん
08/04/02 11:06:33
SpringMVCはシンプルで薄いラッパだから迷うことはないと思う
2.5とそれ以前とでだいぶ中身は違うと思うけど

668:デフォルトの名無しさん
08/04/02 22:41:07
>SpringMVC は、作らなければならないクラスが多い気がしてあまり好きじゃない。
ModelAndView と Contoroller 作るだけなんで
これ以上に少なくってことになると
Teeda で Page に全部詰め込むか
Tapestry で PHP 的なプログラミングするしかない。

669:デフォルトの名無しさん
08/04/02 22:48:57
SpringMVCはどちらかといえばDIベースで作られているのだから
いくらでも好きにいじってください、というものだと思うが

Viewに他のフレームワーク＋Springよりはるかに融通は利くのだが
機能がほしいのならStripseとか普通に使ったほうがいいと思う

Springの他のDIコンテナの追随を許さない圧倒的な利点は
自前でも用意はするし、他のフレームワークの連携も最大限に考慮することだから

670:デフォルトの名無しさん
08/04/03 22:56:24
>>669
Struts連携もHibernate(JPA)連携もSeasarの方が上。

671:デフォルトの名無しさん
08/04/03 23:13:39
ラップして存在を隠すことを連携と言うならそうだろうな。

672:デフォルトの名無しさん
08/04/03 23:34:53
SeasarってJPAとの相性そんなにいいか？
まずトップがJPAを消そうとしてるように見えるんだが

673:デフォルトの名無しさん
08/04/04 00:15:19
>>672
Kuina＞＞＞＞越えられない壁＞＞＞＞JpaTemplate
簡単な問合せはインターフェース書くだけ
URLﾘﾝｸ(kuina.seasar.org)
複雑ならCriteria
URLﾘﾝｸ(kuina.seasar.org)
SQLサポートも強力
URLﾘﾝｸ(kuina.seasar.org)による検索
EntityManager直に使うこともできる。何も隠されてない

674:デフォルトの名無しさん
08/04/04 01:17:22
どうでもいいけど、Springスレにまで出張するのは頭おかしいとおもうんだ
スレまちがえてないか？

それにSpringだってEJBのように直につかえるよ
そもそも何も考えずつ変えるという意味でJPA使うのならEJB3使うのが一番効率的だと思うけど

もともとJPAはオブジェクトプール用に設計されてるからね

675:デフォルトの名無しさん
08/04/04 01:40:11
>>674
>672の問いに答えただけだが

> JPA使うのならEJB3使うのが一番効率的だと思うけど
EntityManager使う面倒さは何一つ解消しないしそもそもSFSBが効率的じゃない

676:デフォルトの名無しさん
08/04/04 02:43:13
何を根拠にSFSBといきなり限定的な話になるのだ

それにステートフルが怖い人ですか
セッションになんでもかんでもぶちこむより活性化、否活性化がちゃんと動くEJBでやったほうがまし
Seasar2ってその辺全部やってくれるの?

677:デフォルトの名無しさん
08/04/04 02:51:01
>簡単な問合せはインターフェース書くだけ
で、_NOT_IN やろうとして失敗して、
コード見たら失敗するのが当たり前で、
ローカルで修正して JAR 入れ替えたらきちんと動いて、
ああ、やっぱり俺悪くないわ、ろくにテストされてねーじゃんとか思うわけだ。

このレベルの項目すらテストされてないのに
他が題目どおりに動くことなんて微塵も期待できない。
それでも Kuina サイコーだってんなら好きにしてくれ。

678:デフォルトの名無しさん
08/04/04 03:11:52
>>676
> 何を根拠にSFSBといきなり限定的な話になるのだ
SLSB+JPAはメリットないからSFSB+拡張コンテキスト限定に決まってるだろ常考
それともSLSB+JPAが効率的とか書いたのか？何が効率的なんだ？

> セッションになんでもかんでもぶちこむより
なんでもぶちこんだらSFSBでもだめだろ

> 活性化、否活性化がちゃんと動く
拡張コンテキストがあると非活性化されない

679:デフォルトの名無しさん
08/04/04 03:46:27
>>677
コミッタに教えてやれよｗ

680:デフォルトの名無しさん
08/04/04 12:16:26
>>678
拡張コンテキストについて詳しく

681:デフォルトの名無しさん
08/04/04 12:32:44
>>680
SFSBのライフサイクルに合わせた寿命の長い永続コンテキスト
永続コンテキストはキャッシュみたいなもん

682:デフォルトの名無しさん
08/04/04 13:30:30
>>680
トランザクション境界ぬけたら非管理下におかれるんじゃないの？

683:デフォルトの名無しさん
08/04/04 13:31:07
>>681
だった。

684:デフォルトの名無しさん
08/04/04 13:50:49
>>682
それ通常の永続コンテキスト

685:デフォルトの名無しさん
08/04/04 13:57:34
KuinaもJPAもEJBもスレ違い

「Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.4」
ｽﾚﾘﾝｸ(tech板)

686:デフォルトの名無しさん
08/04/04 15:00:38
>>684
なら拡張つかうのやめれば？

むしろSFSBはWebに紐付けしないといけないほうが問題。

seamはそのためにあるともいう。

687:デフォルトの名無しさん
08/04/04 20:05:18
>>686
通常のコンテキスト使うならEJB使うメリットはない
SpringでもSeasarでも同等
>674が言うEJBが効率的てのは何なのかと
スレ違いらしいから続けるならO/Rスレで

688:デフォルトの名無しさん
08/04/12 19:25:32
>>686の発言はいみふ

689:デフォルトの名無しさん
08/04/12 19:35:46
>>688
SFSB使ったことないのかい?

690:デフォルトの名無しさん
08/04/12 19:42:09
Swingクライアント+SFSBならWebと紐付け不要

691:デフォルトの名無しさん
08/04/12 22:16:02
>>690
揚げ足取りイクナイ

692:デフォルトの名無しさん
08/04/13 10:19:14
ロジックをステートレスにするのは
フレームワーク側の都合にプログラマが合わしてるだけで
本来の姿じゃないって発言をたまに見かけるが、
ステートフルにするとプログラマの能力を超えてしまう事が多数。

693:デフォルトの名無しさん
08/04/13 13:44:32
つーか、ステートフルであることがアプリケーションの基本でしょ?
そんな基本ができないやつはいらね

難易度が高いのならともかく、基本がないやつは退場してもらったほうが業界のためにいいよ

694:デフォルトの名無しさん
08/04/13 14:25:15
>>693
ロッド・ジョンソンに言ってこい

695:デフォルトの名無しさん
08/04/13 14:39:37
>>693
何が基本なんだかさっぱりわからん
そんなもんケースバイケースに決まってるでしょ

696:デフォルトの名無しさん
08/04/13 20:59:49
ステートレスだのステートフルだのうるさい奴らはSpringの設定を全部シングルトンにしてそうだ。

ステートレスなロジックオブジェクトとステートフルなエンティティオブジェクトのみで
作られたプログラムなんてオブジェクト指向とは到底呼べない。

697:デフォルトの名無しさん
08/04/13 21:02:34
>>696
オブジェクト指向と呼べるかどうかには興味はない

698:デフォルトの名無しさん
08/04/13 22:13:25
>>693
イミフ

699:デフォルトの名無しさん
08/04/13 22:32:42
>>693
退場してください

700:デフォルトの名無しさん
08/04/13 23:00:11
オブジェクト指向万歳！！

701:デフォルトの名無しさん
08/04/13 23:57:46
>>697
オブジェクト指向と呼べるかどうかに興味は無くても
保守性の高い見通しのよいプログラムには興味あるだろう？

ロジックオブジェクトとエンティティオブジェクトを明確に切り分けるのは
そういう観点でも"うまいやり方じゃない"と俺は思うんだが、どうだろう。

702:デフォルトの名無しさん
08/04/14 00:02:02
>>701
保守性の高い見通しのよいプログラムには興味あるだろう？

ロジックオブジェクトとエンティティオブジェクトを明確に切り分けるのは
そういう観点でも"うまいやり方"と俺は思うんだが、どうだろう。

703:デフォルトの名無しさん
08/04/14 00:18:35
「保守性の高い見通しのよいプログラム」を定義してくれ
オブジェクト指向(笑)にすると自動的に保守性が高くて見通し良くなるの？

704:デフォルトの名無しさん
08/04/14 00:27:49
　　　　　　　 ,. .‐'テ'ｰ､-. .､
　　　　　／: : :/ : : : : ヽ : : ＼
　　　　　 ! : r‐┴‐-､: : : l : : : :l l
　　　　　,.∟にﾆﾆﾆﾆlュｭ_l: : : :_l:｣__
　　　／　　　,.ｨ／"＾l　ﾄ､　￣｀`Tﾆ＞
　　/イ,ｲ / /ｺ/┐　iﾋﾍl'ﾆゝ、　 |　　　　　言ってみろよ…！
　　　l/ lｲ/l＝=aﾞ　 ,,=a=＝:l r=､ |　　　　　能書きたれてみろ…
. 　　　　 l.`ー_）　　ー '　|.|ｈ.} |　　　　　聞いてやるよ…
　　　　　　　l　「＿＿_ 　 u |Lノ :ﾄ､
　　　　　ヽ ‘ｰ─‐’　／ﾞヽ　 |: :「:Tｰ-
　　　　_,,　.-‐'|＼￣　／　 u ＼| : |:::|: : :
　‐'' ´: : : : : : |::|: l`:イ　　　　　　 l : j|:::|: : :
　: : : : : : : : :.:|::| : i : ヽ　　　　　ノ : ﾉ|:::|: : :
　: : : : : : : : : |::|: : :＼ :`:ｰ-‐ ': : ／: :|:::|: : :

705:701
08/04/14 00:44:58
>>702
それもそうだな。保守性の高い見通しのよいプログラムっていうのは
多分に人間の感覚に依存してるものだから一概に言えないけれど、

1.プログラムを変更する際に目を通さなければならないファイルが少ない
2.関連するデータと手順は近いほうがよい(推測できる or 同じ場所にある)

上記二点が備わっていたら保守性が高いと言えるのじゃないだろうか？
で、1.の点に関してはロジックとエンティティが同じの方がいいと思える。1ファイルですむからね。
2.の点に関してはロジックとエンティティを似たような名前にする事でどちらでもある程度解消できる。

ただし、プロジェクトでの名前付けの統一に失敗するとロジックとエンティティを切り分けるやり方は地獄を見る。

オブジェクトの責任の切り分けに失敗して巨大なオブジェクトに多量の処理をさせると俺の主張するやり方のほうが地獄を見る。

だから"メンバーに命名規約を遵守させることが出来る"なら702のやり方でもさほど問題ない。
"メンバーの設計が一定レベルにあることを保障できる"なら俺のやり方の方が冴えてる。

と、思うのだがどうだろう。ちなみに俺はオブジェクト指向についてはそれほどこだわらない。
分かりやすく保守しやすいコードを一番重視する。

706:デフォルトの名無しさん
08/04/14 00:53:45
　　　　　　､-‐- ､,. z_
　　　＜￣　　　　　　ゝ
　 ∠´　　　 /Vヽ　　　ゝ
∠　　 ∧/`'　　ﾑ,　　　　ヽ　　　なんや　おどれと話をしてると
∠/レ'　　　　　　ム　 _,_　 `、
　| 　 ,.－　　　　　ヾ（へヽ　ヽ　　　わいも落ちるとこまで落ちたって
　|／　／ﾄ､ }　　　　ヽV~) ）　ヽ　　　　気になるわ…
　＼ヽノ､ｼ　　,.ｲ　　ヾ '　　 }
　,/　　 `｀　ｰ-―- ､　　ヽ.　　　l
　L　r っ　 _. -‐ォ　）　　）＼　／⌒ヽ
　　　 (二´-‐_'´ノ　　　／　 .／　　　　〉、
　　　 (二´-‐ '　､ ` ／　,／　　　　 /　＼
　　　　　＼ヽヽ` ／　／/　　　　　　/　　　ヽ
　　　　　　　` ｰ 'ヽ／　/　　　　 , ' 　　　ヽ
　　　　　　　　　　/ヽ. /　　　　　／　　　　　ヽ

707:デフォルトの名無しさん
08/04/14 01:11:28
特にwebアプリケーションにおいては、ステートフルなオブジェクトが多いと
スレッドセーフとパフォーマンス面で実装が難しくなって
かえって複雑になるという現状があるからなぁ。

708:デフォルトの名無しさん
08/04/14 01:33:53
つまり結局「有能な人間を集めればうまくいきます」ってこと？
もはやオブジェクト指向もDIコンテナも関係ないな(爆笑)

709:デフォルトの名無しさん
08/04/14 01:37:38
どうしてそんな結論に至るのかまったく理解不能。

710:デフォルトの名無しさん
08/04/14 01:46:28
>>707
現状じゃなくて昔はの間違いでは?
マシンパワーが低いとかの問題で。

スレッドセーフの問題はどちらの場合でもついてくる。

711:デフォルトの名無しさん
08/04/14 01:57:09
>>664
FreeMarkerってstruts2が中で使ってた

712:デフォルトの名無しさん
08/04/23 20:08:53
HibernateもFreeMarker中で使ってるんじゃなかったっけ。

VelocityよりFreeMarkerの方が二番煎じな分だけ使いやすい気がする。

微妙にスレチ下げ。

713:デフォルトの名無しさん
08/05/06 01:56:23
Spring1.3→2.5とジャンプアップを企んでいる者です。
質問なのですが、アノテーションを使ってDIしてる場合、UnitTestってどうやりますか？

1.3の時代はsetterインジェクションをしていたので、
ドライバクラスからテスト対象クラスをnewし、スタブクラスをsetしてやればテストできたのですが、
アノテーションを使うとsetterが無いのでスタブをsetできません。

この場合、UnitTestでもSpringを使う必要があるのでしょうか？

714:デフォルトの名無しさん
08/05/06 02:33:33
>>713
アノテーション使おうがsetterを使えば同じようにできる
フィールドインジェクションの場合は無理

でも、AOPとかトランザクションとか複雑に絡み合うコンポーネントを考えると
単体テストでもコンテナから呼び出したほうがいいかと

結果、ある程度の結合テストができていると考えていいし

問題が大きいようだったら2.5でもアノテーションつかわなくてもいいんだよ
2.0までのやり方でも問題はない

715:デフォルトの名無しさん
08/05/07 18:43:41
>>712
FreeMarkerは開発者が人間のクズ。

716:デフォルトの名無しさん
08/05/08 01:16:44
>>715
どういうこと？

717:デフォルトの名無しさん
08/05/10 11:23:12
流れぶったぎってすまんが、Spring使ってると
xmlやらインターフェースが増えてうざいし
ほんとに便利なのかコレ

718:デフォルトの名無しさん
08/05/10 16:16:06
>>717

アノテーションつかえばXML書かなくてもいいよ。
インターフェースも必要なければつかわなくていいよ。

719:デフォルトの名無しさん
08/05/10 17:11:13
>>717
いつの人ですか？

今は自動で登録できるよ
自動登録するパッケージを指定して
@Componetとかクラスの定義につければよい

720:デフォルトの名無しさん
08/05/10 17:22:54
Spring（というかDI/AOPコンテナ）使わないと自分でインスタンス管理しなくちゃいけないし
トランザクションも管理しなくちゃいけないし、AOPも使えなくてえらく不便だ。

721:デフォルトの名無しさん
08/05/10 17:37:15
通常のGUIアプリとかだとDIコンテナが使い物にならなくてワロタ
ならよくある

インスタンス管理はどのフレームワーク使おうが意識をしないってことはないと思うが

722:デフォルトの名無しさん
08/05/10 17:44:46
意識しないなんて誰か言ったか？

723:デフォルトの名無しさん
08/05/10 17:53:33
インスタンス管理を意識する・しないじゃなくてインスタンス管理のための仕組みを自分で作るかどうか。
既にそういう機能を持ったフレームワークがあるのな自分で作るのはバカバカしい。
DIコンテナいらねって人はインスタンスを管理するという発想がないのかもね。

724:デフォルトの名無しさん
08/05/10 17:56:51
つまりwicketはだめでJSFは最高というわけですね

725:デフォルトの名無しさん
08/05/10 18:01:03
アホか。

726:デフォルトの名無しさん
08/05/10 18:26:54
JSFって良いか？
もうRESTな作りできるようになったんだっけ？

727:デフォルトの名無しさん
08/05/10 18:39:10
REST厨ってHTMLのstrict厨と同じ臭いがする

728:デフォルトの名無しさん
08/05/10 19:38:07
技術が細分化してて向き不向きがはっきりしているってことだよね。

729:デフォルトの名無しさん
08/05/10 22:40:20
技術というか単なる道具とかテンプレートだよな…

730:デフォルトの名無しさん
08/05/10 23:38:15
論文がどうだとか言い出すREST厨は嫌いだが
RESTがRIAと相性がいいのは確か

731:デフォルトの名無しさん
08/05/11 00:33:59
RIAといってもクライアントがさまざまだからなんとも

アプレット/JavaWebStart/.NET関連だとSOAPはやっぱり楽だし（JAX-WS2.1あたりで互換性解決したし）
鯖サイドがJavaでjavascriptだとDWR使ったほうが楽だったり

732:デフォルトの名無しさん
08/05/11 01:21:25
SOAPは遅すぎてRIA向きじゃない
JavaScriptのライブラリが急速進化し、開発環境が整備されてきた今では
DWRも過去の遺物だろう
Ajax、Flex、Silverlightのどれでも開発出来るように
JAX-RSのような形態を取るのが今後の標準だと思う

733:デフォルトの名無しさん
08/05/11 01:30:02
RESTみたくゆるい仕様ってツールサポートしにくくね？
ツールのサポートなくても平気のがゆるい仕様なんだろけどさ
JAX-RSのメタ情報って他言語から使えるんか？
SOAPはいらんけどWSDLぽいのは必要じゃねーのか

734:デフォルトの名無しさん
08/05/11 01:54:31
スレ違い
ｽﾚﾘﾝｸ(tech板)

735:デフォルトの名無しさん
08/05/11 02:47:17
>>732
だからクライアントしだいだろ？
WSDLによるクライアントの開発の容易さは捨てがたいだろう。

それにDWRが過去って。
やっと2.0になってリバースAJAXでかなりよくなったところなのに。

どれでも開発できるようにってのは下手するとこけるからね。
まぁバックエンドのサービスをEJB等できっちりつくっておいて
インターフェースを自由にできるようにしておいたほうがいいと思われ。

736:デフォルトの名無しさん
08/05/11 15:49:55
好きなものを使えってことで。

俺は WebService(WSDL) が好きなんだが
Microsoft のサポートがプアなのがなあ。

737:デフォルトの名無しさん
08/05/14 20:00:58
329 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/13(火) 22:04:29
冷ややかな戦争勃発ｗ
URLﾘﾝｸ(d.hatena.ne.jp)

342 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 02:05:36
はぶ参入で抗争激化！さぁ、盛り上がってまいりました！

343 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 02:08:47
とりあえず、保存しといた。
URLﾘﾝｸ(s04.megalodon.jp)

347 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 07:16:26
面白くなってきたな。Seasar界隈は人格的にちょっとあれな人が多いのが魅力w

348 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 07:40:37
でも、理事のBlogでやることじゃないよこういうことはメールベースでやるべきだと思う
野次馬的には面白いかもしれないけど企業から見たら不安になって採用を躊躇するところが出てきてもおかしくないからね

352 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 14:02:42
マーケ的にまずいのでseasar3はとりあえず表に出さないでくださいとかいうのはちょっとやばい

353 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 14:04:14
元理事は一旦収束していたのに、なにをしたかったのだろうか。そして日記非公開の理由とは・・・？asipの参戦はありうるのか！？

354 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 14:08:14
うわ、ほんとだ閉鎖した

355 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 16:31:01
DB関連とか色々勉強させてもらったけど、このしみったれた感覚が所詮デブオタなんだなと思うわ。

738:デフォルトの名無しさん
08/05/14 22:07:47
擦れ違いかもしれんが、
Jboss seam使っているやついる？

stateless session bean と普通のPOJOのビジネスロジックの使い分け方が、
わかんね。

739:デフォルトの名無しさん
08/05/14 22:16:39
汎用フレームワークの話ならこっちじゃね？
ｽﾚﾘﾝｸ(tech板)

セッションビーン使えるならロジックはすべてそっちでいいと思われ。
POJOのほうはView関連に特化させるといい感じかな。

740:デフォルトの名無しさん
08/05/14 22:35:14
あ、そんなスレあったんだｗ
サンクス。

741:デフォルトの名無しさん
08/05/14 23:02:38
春よコイ！

742:デフォルトの名無しさん
08/05/15 18:14:48
>>716
亀レスだが
ｽﾚﾘﾝｸ(php板:34番)

743:デフォルトの名無しさん
08/05/15 22:38:16
俺ずっと REST は RDBMS の CRUD に対応するもので、
言うなりゃ SQL とかストレージ的な空気をクライアント側から
隠匿するためだけの物に近いと思っているんだが
いっつも SOAP とか RPC とかと同列に語られてるんだよな。

REST で騒いでる奴らって CRUD だけで済むプアーなアプリを作ってるからそういう事言ってるの？
それとも REST 風(つまり、単に定義のゆるいWeb-API)なものと混同してるの？馬鹿なの？

744:デフォルトの名無しさん
08/05/15 23:26:32
>>743
何を言ってるのかサッパリだわ

745:デフォルトの名無しさん
08/05/15 23:34:33
>>743
狂っどる

746:デフォルトの名無しさん
08/05/15 23:52:56
>>743
SOAな連中が語るRESTとROAな連中が語るRESTは別物

747:デフォルトの名無しさん
08/05/16 08:14:09
>>746
ああ、なるほど。>>743が何言ってるのかわかった。
SOA(笑)方面ではそういう扱い方をするのか。
つーかRESTなんて単なる道具なんだよ。
どういう使い方を語ろうと勝手だろうに。

748:あぼーん
あぼーん
あぼーん

749:デフォルトの名無しさん
08/05/18 18:34:39
おまいらSpringと一緒にORマッピングは何つかってんの？
俺はiBatisが分かりやすくて気に入ってる。

750:デフォルトの名無しさん
08/05/18 20:16:17
>>749
Hibernateかな。
これが一番普及してそうだし。

751:デフォルトの名無しさん
08/05/18 21:37:15
>>749
Hibernate
マッピングはEclipseに自動生成させて
CriteriaとQueryを中心に使う

752:デフォルトの名無しさん
08/05/18 22:06:39
>>749
JPAかな
次期HibernateではネイティブでJPA対応するし、各種ツールがそろってるのは大きい

753:デフォルトの名無しさん
08/05/18 22:16:53
>>749
DBUtils

754:デフォルトの名無しさん
08/05/18 22:36:50
Hibernateって設定ファイル多くてメンテしにくそうなんだが。
確かによく聞くっちゃ聞くけど。JPAのPJにはまだ当たった事無いです。

>>753
それってJakarta DbUtils？
ORとは違うけど確かに一番便利な気がする。
Springに組み込まれればいいのにな。

755:デフォルトの名無しさん
08/05/18 23:32:44
>>754
JDBCテンプレートがそんなもんだな

756:デフォルトの名無しさん
08/05/19 01:44:17
DbUtils は、DI コンテナとか知らないときによく使ってたが、
DbUtils と DI をどうやって組み合わせるの?

サービスオブジェクトに DAO オブジェクトを DI させて、
DAO の実装は Hibernate とか iBatis でなく DbUtils を使う感じ？

757:デフォルトの名無しさん
08/05/19 02:14:22
>>756
QueryRunnerにコネクションを渡すんだろうけど
それってどうなんだろう・・・　Springが勝手にやってくれるとこを
わざわざ記述しないといけないのかね。

758:デフォルトの名無しさん
08/05/19 07:21:33
DBUtils の QueryRunner とか *Handler は大抵 JDBCTemplate で代用出来ると思うが。

759:デフォルトの名無しさん
08/05/19 08:33:09
>>754
HibernateはJPAに対応しているから設定ファイルはpersistence.xml一個だよ
EntityのマッピングはJPAのアノテーションが使えるし、
それはEclipseのWTPなら自動作成できる

DBUtilsはO/Rマッパー使う前は愛用していたけど
今の時代では流石に使う気になれないな

760:デフォルトの名無しさん
08/05/19 13:14:10
JPAが一番楽だろうね
有名どころのIDEはみんな対応してて設定ファイルはまったくいらないし

761:デフォルトの名無しさん
08/05/19 21:31:47
Hibernateが一番楽だろうね
voクラスの自動生成とcrudアクセスを多用すればジェネリックスの恩恵にあずかれる
まさに楽チン

762:デフォルトの名無しさん
08/05/19 22:28:18
ここ半年前までは、
・Hibernate ウンコ!!
・余計なことしすぎ (n+1問題など)　　←使いこなせてない側の問題があるがここでは目をつぶる
・iBatis みたいなの便利!!

というかんじで Hibernate はぼろぼろだったが、JPA の登場により王者復活か?

どれ、おれも本買ってもう一度やってみるか

763:デフォルトの名無しさん
08/05/19 23:06:39
>>749
ORMは使ってないなあ。
ものすごく薄いDAO層のラッパ作成して
(JdbcTemplate 使うようなやつ)
基本的にSQLそのまま書く。
SQL実行するためのツールがそのまま使えるのが大きい。

でも思ったよりも ORM 使う人多いのね。

764:デフォルトの名無しさん
08/05/19 23:11:22
>>763
spring使ってるのか？

765:デフォルトの名無しさん
08/05/19 23:36:53
>>764
JdbcTemplate使ってんなら当然だろ

766:デフォルトの名無しさん
08/05/20 00:52:06
>>762
JPAの範囲だけ見るとHibernateは確かにあまりよくない
LAZYが何も設定せずにきくのはTopLinkとApache OpenJPA

OpenJPAはManyToOneでもn+1フェッチしないんだよね
joinを積極的に使う戦略のようだ

あとupdateがHibernateが一番頭が悪かった
項目ひとつだけ変更してもすべての項目をアップデートしに行くのはHibernateだけ
ほかの実装は更新された項目だけupdateする

767:デフォルトの名無しさん
08/05/20 00:59:58
>>766
> ほかの実装は更新された項目だけupdateする

それだとバッチ更新できなくね？

768:デフォルトの名無しさん
08/05/20 01:02:51
>>766
ManyToOne、OneToOneにはFetchType.LAZY付けるのが基本だと思う
必要なときだけQueryやCriteriaでJOINすればいいんだし

769:デフォルトの名無しさん
08/05/20 01:09:00
iBatis派少ないな。
まぁ結局そんなの使わずにSQL直書きが後で一番見やすいのは
確定的に明らかだがな。

>>758
無理

770:デフォルトの名無しさん
08/05/20 01:17:45
>>767
どういうこと？

>>768
もちろんLAZYが一番よい
Joinして持ってきたいときにはそう書けばいいだけだし

Hibernateの問題はLAZYがJPAでまともに実装されていないこと
独自のアノテーションが必要

771:デフォルトの名無しさん
08/05/20 02:12:12
>>769
iBatis は悪くないんだけど、だったら SQL でいいじゃん
てところに落ち着いてしまうのでは。
とことん抽象化するか、とことん具象で済ますかの二択で。

772:デフォルトの名無しさん
08/05/20 02:15:29
>>771

んな事ねーんじゃね？

Beanへのマッピングとか便利でしょ、、、てかORマッピングってそこじゃねーの？

773:デフォルトの名無しさん
08/05/20 02:38:25
JPAもネイティブQueryでnewが使えると最高なんだけどね

774:デフォルトの名無しさん
08/05/20 07:04:09
>>770
独自アノテーションは微妙だな
せめてpersistence.xmlのpropertyでlazyの挙動を切り替えられるようにして欲しい

>>773
個人的にはnewよりもHibernateのResultTransformerをJPAの仕様に入れて欲しいかな
あれさえあればSQL使うときも戻り値を好きにできるので便利

775:デフォルトの名無しさん
08/05/20 08:08:02
>>772
Object-Table Mapping ならそうなんだろうけど
いかんせん Relation だから・・・重厚長大でどうにも。

776:デフォルトの名無しさん
08/05/20 09:13:14
ｵﾚ的にはiBatisに重厚長大感はないけどな？？
重厚長大っていったらHibernateじゃないの？

っでｵﾚはiBatis派なんだが

777:デフォルトの名無しさん
08/05/20 21:17:50
>>776
単に使った事無いだけでしょ。
ORも正しく理解できて無いし、相手するだけスレの無駄。

778:デフォルトの名無しさん
08/05/20 21:37:13
このスレの人たちは、フレームワークが道具であって目的ではないことを忘れ去ってますね

779:デフォルトの名無しさん
08/05/20 22:33:47
>>778
道具だからこそこだわるんだろ？
こだわりがいらないのならSeasarつかうさ

780:デフォルトの名無しさん
08/05/20 22:50:39
>>779
Seasarって、サラダで食べるくらいだなｗ

781:デフォルトの名無しさん
08/05/20 23:01:52
>>779 どういう事？

782:デフォルトの名無しさん
08/05/21 01:57:38
Seaserの方が優れているという事だが
デファクトスタンダードという事でおまいらは
Springに固執しているのか？

俺がそうなんだけどよｗ

783:デフォルトの名無しさん
08/05/21 02:03:48
>>782
>>780

784:デフォルトの名無しさん
08/05/21 08:13:09
>>782
リファレンスドキュメント読んで、
あるいはソースのコメント読んで
どっちが信頼にたるか考えたらいい。
悩むほど難しい選択ではないはず。

785:デフォルトの名無しさん
08/05/21 12:21:31
MLのホットデプロイのスレわろたｗｗｗ

786:デフォルトの名無しさん
08/05/21 21:50:21
>>785
どういうやつ？

787:デフォルトの名無しさん
08/05/21 23:13:22
iFitって使ってる人居る？

788:762
08/05/22 22:27:13
>>769
iBatis はよく使っているよ。
だけど、iBatis ばかりで Hibernate は使いこなせてないので、
くやしいので Hibernate を勉強している。

いろいろ思いはあるのだが、こっちに書くとスレ違いかな(O/Rマッパースレに移るべきかな)

789:デフォルトの名無しさん
08/05/22 23:10:04
JPAは勉強はあまり必要とはしないと思うけどね

790:デフォルトの名無しさん
08/05/22 23:13:00
今Hibernateを勉強するなら、一通りJPAを学んだ上で
CriteriaとSQLQuery、一部の独自アノテーションと二次キャッシュを学べばいいと思う
Hibernate独自の設定ファイルはもう使うことは無い

791:762
08/05/22 23:25:46
Hibernate 3.2 を使っていたとき(JPA は使っていない)、
Hibernate tools で DB からテーブル情報抜き出して(ant hbm2hbmxml)、
目で確認して、一部手作業で修正、
Spring からは、Spring 入門の8章での使い方をした(HibernateSupport のサブクラス)

n+1 や lazy は、koichik 氏のブログを読み漁って、理論は理解しているつもり。
プロジェクトでは、テストしてパフォーマンスが悪ければ join するようにし、
パフォーマンスが問題にならなければシカトしていた。

>>790
JPA 使うと、テーブルごとの hbm.xml がいらなくなるということ？

去年の Seasar カンファレンスで、「流れるようなインターフェース」で
S2jdbc のやつがあったが、JPA もそんな感じなんだよね。

中村氏の本、Spring でなく Seasar だけど読んでみようかな。

792:デフォルトの名無しさん
08/05/22 23:37:59
>>791
hbm.xmlもcfg.xmｌも要らない。JPAのpersistence.xmlだけで設定は済む
Springが提供するHibernateやJPAのラップクラスはあまりお勧めしない
SpringはJavaEE5標準方式のJPAのDIに対応しているので、
それを使って直接EntityManagerを使った方が何かと簡単

793:デフォルトの名無しさん
08/05/23 00:52:24
WEBアプリ最強はSpring + Struts + Hibernate?

794:デフォルトの名無しさん
08/05/23 01:14:40
最強はフレームワークに振り回されずに本質を見極める人材です

795:デフォルトの名無しさん
08/05/23 01:26:00
>>791
紺色のＥＪＢ３本が日本語でもっともＪＰＡを詳しく解説してある本かと
EJB3の中の一仕様だからね＞JPA
ただし、JavaSE上で単体でも使えるようにしたと

JPAをもっとも快適に使うためにはJavaEEのほうがいいと思うけど

勉強なんて大げさなものは必要ないよ
NetBeansで自動生成されるコードを見れば大概わかるかと

796:762
08/05/23 01:39:16
レスどうもありがとうございます。

>>795
URLﾘﾝｸ(www.amazon.co.jp)
これですね。とりあえず立ち読みしてきます。

>>792
Spring 入門は Spring 1.2 のころだけど、
いまどきの Spring + Hibernate(JPA) の連携の仕方は、
HIbernateDaoSupport ではなく、新しいやり方があるということですね。

797:デフォルトの名無しさん
08/05/23 07:31:31
>>796
SpringのドキュメントのJPA部分を読めば一通り説明が載ってる
JavaEE5サーバ上で動かす場合は
URLﾘﾝｸ(static.springframework.org)
TomcatやJ2EE1.4以下のサーバで動かす場合は
URLﾘﾝｸ(static.springframework.org)
12.6.2のJpaTemplate、JpaDaoSupportは無視して、12.6.3で@PersistenceContext
を使っている例を参考にするといいと思う

798:デフォルトの名無しさん
08/05/23 12:09:43
>>796
そうそう
それ読むとDIコンテナもEJB3でいいじゃないかということになるはず

799:デフォルトの名無しさん
08/05/24 15:00:12
今のプロジェクト、EJB3かspringかどっちでいくかホント迷う

800:デフォルトの名無しさん
08/05/24 15:39:06
開発環境がNetBeansとか運用環境がGlassfishならばEJB3のほうが楽。

その他ならばどっちでも同じ。

801:デフォルトの名無しさん
08/05/24 17:10:57
DIコンテナに限った話ではないけど
両方使ってみて、プロジェクトに合う方を選べばいいと思う

802:デフォルトの名無しさん
08/05/24 18:30:50
メンバの経験が多いほうがいいに決まってるでしょ

803:デフォルトの名無しさん
08/05/24 18:39:35
>>802
それはメンバにもよる

804:デフォルトの名無しさん
08/05/24 19:35:21
誰か>>803の解説を頼む

805:デフォルトの名無しさん
08/05/24 20:00:25
経験が多くても当てにならない・・・ってことかな？
たぶんレス番号のミスかと

806:799
08/05/24 20:08:28
メンバは数人で誰もどっちも経験なし。
短納期なんでEODの面と保守時のコードの分かりやすさや、
xmlファイルの少なさからEJBかと思ってるが、あまり普及してないらしいのがマイナス。
後から違う保守要員来たときを考えると流行りのSpringかな？決め手がない

807:デフォルトの名無しさん
08/05/24 21:05:28
>>804
メンバの技術水準が高ければ、
学習コストよりもプロジェクトに対するFWの相性の方を優先できる
技術水準が低ければ、学習コストを重要視する必要があるので
経験者が多いFWの方が候補になりやすい

808:デフォルトの名無しさん
08/05/24 21:27:34
>>806
DB層はJPA?

あとInfoQとか見てるとEJB3は最近わりと地味に普及してきている感じかな
Springは古い1.x時代のは多かった

809:デフォルトの名無しさん
08/05/24 22:16:12
>>808
うん。ORMやりたいんでJPA考えてました。
ちなみにDBのERDは教科書に出てくるくらいのレベルに近く、かなり単純なんで
ちゃんとテーブル設計してマッパーが吐くsqlがインデックススキャンになるようにするのは難しくない、という読み。
EJBといいつつ、分散システムでもなんでもないんだけど、とにかくデリバリを早く、でも保守は用意に、というのが
プロジェクトの主眼です。

810:デフォルトの名無しさん
08/05/24 22:30:12
短納期で経験のない技術を選ぶってリスキーじゃね？
はまった時にリカバリできるのか？

811:デフォルトの名無しさん
08/05/24 22:43:07
>810
SpringはともかくEJBってそんなに難しいの？
商用or無償APサーバ＋サーブレット＋JSP＋struts or 自社FW なら経験あるから
何とかなるかと思ってた
自分でも保守やるし、またJDBCゴリゴリのソース相手にするのが嫌なんだ

812:デフォルトの名無しさん
08/05/24 22:47:29
EJB3ならそんなに難しくは無い
ただしSpringに比べてDI・AOP機能に色々制限があるから
予めプロトでも作って要件を満たせるかどうか確認した方がいいと思う
JPAもCriteriaが標準化されてないという弱点があるから
検索画面で動的にSQL組み立てる処理が多ければ、最初からHibernateなどの
独自Criteria機能を使うことを頭に入れて置いた方がいい

813:デフォルトの名無しさん
08/05/24 22:57:47
EJB3.1のほんの一部がGlassfishV3で触れるようになったが、かなりよさげだね。

>>811
難しくないよ。
EJB3.0で2本ほど納品済みだけれども、開発効率は非常によかった。
むしろ小規模向きだと思う。
EJB3にしろSpring2.5にしろ、ひとつ覚えておけばその後はどうにでもなる。

>>812
AOPってそんなに使う？
メインはトランザクションなんだろうけど、EJBならばその用途では必要ないしね。
JPAもHibernate依存するのは今はよくないような。
パフォーマンスも問題になるとは思えないしね。

JPQLでDTOを直接生成することも出来るのであんまり困ることはないけど、
パフォーマンスが命でなければEntityからDTO生成するほうがいいかもしれない。

そもそもJPAのプロバイダとしてはHibernateが一番パフォーマンス的にも出来が悪いので注意かな。

814:デフォルトの名無しさん
08/05/24 23:06:28
EJBの本質は分散処理だと思うが、 >>809 のような分散システムでもなんでもない
web アプリを作る場合、
Tomcat + (Spring +) JPA と、
Glassfish + ejb3 は、パフォーマンスとしてはどちらが速いのだろう?

>>813
AOP は結構使います。ロギングとか。
あとから顧客のうざい要求によって仕様変更があったとき、
既存クラスを変えずに、ログ出力やデータ変換の処理を差し込めるのは
楽だと思う。

815:デフォルトの名無しさん
08/05/24 23:09:15
>>811だけ読んでも俺ならリスク高いと思うけど。
「JDBCゴリゴリのソース」、「自社FW」
こんなのいつから止まってるのって話だろ。
現状を嫌だと思ってる（問題視してる）のが811のみだったら爆発するぞ。

短納期だし、とりあえずチームの得意な形＋ORマッパでDao層だけ剥がすのが無難だと思うがなぁ・・・

816:デフォルトの名無しさん
08/05/24 23:10:55
>>811
難しいかどうかじゃなくてさ、時間あるときに触ってもないのに
いきなり実戦投入ってのがありえねーと思ってさ。
そういうやつが痛い目あうとEJB使えねーSpring使えねーって
言い出すからな

817:デフォルトの名無しさん
08/05/24 23:11:10
Local呼び出しにしろ、web-ejbコンテナ間のオーバヘッドがあるから、
Tomcatが勝つんじゃないの？

818:デフォルトの名無しさん
08/05/24 23:15:08
sunには賛成できない

819:デフォルトの名無しさん
08/05/24 23:19:00
TomcatでSpring+JTAって終わってるんじゃないの？
まさかずっとメンテナンスされてないJTOMとかつかっちゃうなんてことは出来ないだろうし

Tomcatも管理するのはたるいよね
GlassfishとかAP鯖だと管理ツールが便利だな
GUIで各種コンポーネントのロギングレベル変えたりとか

Tomcatの範囲だけでもGlassfish使うのお勧め
JTAやデータソース、コネクションプールのチューニングとかそっち方面任せるだけでもかなり楽

820:デフォルトの名無しさん
08/05/24 23:20:57
2PC使わなけりゃJTAいらん

821:デフォルトの名無しさん
08/05/24 23:28:38
>>813
AOPはトランザクション用途以外だとログやセキュリティ関連とかで結構使う
SpringはいざとなったらAspectJのフル機能を使えるから、
AOPに関しては何でもアリ状態なのが強み

Web画面は結局は動的Queryによる検索処理が殆どだから
JPAが持ってないCriteria系機能が有るのと無いのとでは生産性が大きく違う
以前JPAのAPIに拘ってCriteriaを採用せず、後で痛い目にあったからよくわかるｗ
Criteriaに関してはHibernateがいちばん機能が充実してるように感じる
TopLinkはCriteria系に関する情報がWeb上にほとんど無いし
OpenJPAはざっと見たところCriteria機能そのものを持ってないっぽい

>>816
結局は、事前にしっかり調査をするかどうかだと思う
開発者に経験がないのなら、事前にアーキテクト的立場の人間が
一通りの機能を確認しておくべき。適当に事前印象だけで決められて
開発フェーズになってからあれも出来ないこれも出来ないと
言い出されるのが一番困る

822:デフォルトの名無しさん
08/05/24 23:28:44
>>814
GlassfishのWebコンテナはTomcatベースだけどNIO使ったりIO方面でチューニング済み
JBOSSとかもそうだったはず。

>>820
コンテナ管理のトランザクションならJTA使うだろ？

823:デフォルトの名無しさん
08/05/24 23:30:49
>>820
Connectionからトランザクション管理を独立できることに意味があるので
2PC使うかどうかは関係ないな
JPAもJTAを直接見てるから、JPAと連携させるのなら尚更JTAが望ましい

824:デフォルトの名無しさん
08/05/24 23:33:29
ロギングだけならどのDIコンテナでもそんなに問題になるとは思えんが
EJB3の場合Interceptorsを必ず付与するようにしておいたほうがいいかもね

>>799は小規模ということであんまり問題にならないと思うけど

とりあえず小規模なうちにDIコンテナとか一通りの勉強しておいたほうがいい
今後JavaEE6やJavaSE7でまた大きく変わるからね

JavaEE5の時代のうちに世の中に追いついておいたほうがそのとき覚えるものが少ないかと

825:デフォルトの名無しさん
08/05/24 23:42:51
>>822,823
SpringだとJTAなくてもコンテナ(Spring)管理のトランザクション使える
2PCがいらなけりゃJTAはいらん

826:デフォルトの名無しさん
08/05/24 23:44:39
>>823
> JPAもJTAを直接見てるから、JPAと連携させるのなら尚更JTAが望ましい

EntityTransactionは無視ですかそうですか

827:デフォルトの名無しさん
08/05/24 23:45:55
>>825
その考えがもう古いんだよ
JPAはJTAを用意できないとRESOURCE_LOCALモードになってしまうし
最近はSpringを介さず直接JTAを見るO/Rマッパーが殆どだぞ

828:デフォルトの名無しさん
08/05/24 23:50:03
>>827
2PC使わなけりゃローカルモードで十分だろ
何のメリットがある？

829:デフォルトの名無しさん
08/05/24 23:52:44
>>828
JPAのコンテナモードそのものがJTAモード前提になってる
実装によってはコンテナモードとローカルモードで挙動が変わる
一度JPA仕様をしっかり読むことをお勧めする

830:デフォルトの名無しさん
08/05/24 23:52:48
>>827を支持しよう
SpringにしろSeasar2にしろJTAとデータソースをJNDIで持ってくるのが正解（EJB3の場合全自動）かと

RESOURCE_LOCALとかスタンドアロンアプリ以外ありえん

831:デフォルトの名無しさん
08/05/24 23:55:47
>>829
コンテナモードがいらんだろ

832:デフォルトの名無しさん
08/05/24 23:57:44
id:shinとかid:da-yoshiとかいそうな流れ

833:デフォルトの名無しさん
08/05/25 00:04:04
このスレ見てると道具の進化に踊らされる猿たちって感じだな

834:デフォルトの名無しさん
08/05/25 00:08:18
glassfish厨は専スレ立てたらどうかと思うんだ

835:デフォルトの名無しさん
08/05/25 00:11:59
GlassFishの話だったのか？
APサーバでSpringというパターンが多いからピンとこなかった

836:デフォルトの名無しさん
08/05/25 00:18:40
>>835
>813,819,822

837:デフォルトの名無しさん
08/05/25 00:22:55
>>836
ああ悪い、TomcatとAPサーバという話が並行して行われていたのかｗ
TomcatならたしかにJTA使うのが前提にはならないな
個人的にはSpringの仕事はAPサーバばかりなんだが、
やっぱりTomcatで動かしてる現場の方が多いのだろうか？

838:デフォルトの名無しさん
08/05/25 00:32:45
>>832以降、JTA厨がいなくなった件w

839:837
08/05/25 00:38:29
>>838
いやいるけどｗ
自分のやった仕事はほとんどがAPサーバ前提だったから
SpringでもJTAを選ばないという選択肢をしたことは無かった
あまりTomcat案件そのものに当たったこともないんだけど、もしかして自分は少数派なのか？

840:デフォルトの名無しさん
08/05/25 00:40:23
＞以前JPAのAPIに拘ってCriteriaを採用せず、後で痛い目にあったからよくわかるｗ
なんで調べてから使おうとしないのか理解に苦しむ。

次ページ