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

Java Spring Frameworkを語るスレ

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさんNGNG
http://www.springframework.org/

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

語るべし。
0925デフォルトの名無しさん2007/01/19(金) 07:36:17
>xml添付しまくるデスクトップアプリって
>なんかかっこ悪いし。
いみふ
0926デフォルトの名無しさん2007/01/19(金) 07:47:47
XML使ったら負けかなと思っている
0927デフォルトの名無しさん2007/01/19(金) 07:51:04
>XML使ったら負けかなと思っている
さらにいみふ
0928デフォルトの名無しさん2007/01/19(金) 07:52:34
アホとしか言いようがない
0929デフォルトの名無しさん2007/01/19(金) 07:57:32
アホとは言わないが論理的でないよね。
Spring良さそうな噂を聞いて使ってみようかと思ったけど、
それにはそれなりの学習コストが必要であるのがわかって、
そこまではしたくない言い訳にいみふなことを連発しているだけだと推測する。
0930デフォルトの名無しさん2007/01/19(金) 07:59:38
混同してない?
SpringとEJBは別腹よ?w
0931デフォルトの名無しさん2007/01/19(金) 10:56:19
>>918
確かに意味不明な文になってた。すまん。

JdbcTemplate や JmsTemplate、DisposableBean
とかを使う場合、Spring に依存した実装になるんだけど
POJOでウハウハな思想だと、なるべく依存部分は減らしたい。
で、そういう場合に

1. 依存しててもいいじゃない。
2. Springから独立した部分と依存部分にわけて、
 独立部分がアダプター経由して依存部分を使用する。
3. XML定義で済むなら無理して使わない。(init-method 書けば済む InitializedBean など)

のどの方針で行ってますか?と。ケースによる使い分けとか、
もっとスマートな方法でやってるとか。
そんなことを聞きたかった。
0932デフォルトの名無しさん2007/01/19(金) 12:07:11
>931
外部リソースを使用する限り、必ずどこかでそれらに依存して実装しなければならない部分はある。
だから依存してる部分としてない部分をハッキリさせておくことが重要なんじゃないかな?



IFきってあるDAOだけならいくらでも依存させておけ
0933デフォルトの名無しさん2007/01/19(金) 12:31:48
まぁクライアントサイドだと自前でパラメータを動的にコンストラクタで生成すること多いってのはある
0934デフォルトの名無しさん2007/01/19(金) 14:16:22
賛成
http://d.hatena.ne.jp/higayasuo/20070119#1169180656
0935デフォルトの名無しさん2007/01/19(金) 16:50:29
>>932-934
ご意見どうもでした。
と言うか、盛り上がりようもないくらいに
当たり前の結論に至ってしまった・・・
0936デフォルトの名無しさん2007/01/19(金) 17:39:57
springを使ってシステム開発しようかと思っているのですが、
皆さんはデータベースアクセスにどんなツールを使ってますか?
Hibernateが多いのでしょうか?
0937デフォルトの名無しさん2007/01/19(金) 19:58:46
今はJPAだろ?
実装は好きなの使ってもいいが、それぞれ癖をつかんどけ
0938デフォルトの名無しさん2007/01/19(金) 21:56:28
なんで今はJPA?
0939デフォルトの名無しさん2007/01/19(金) 22:37:08
目立てるから
0940デフォルトの名無しさん2007/01/19(金) 23:34:01
デスマーチが好きだから
0941デフォルトの名無しさん2007/01/20(土) 01:19:33
あーでもクライアントアプリで設定ファイルでもないのに
xml使ってるってのはスマートじゃないって気はするね。
感覚的に、だけど。
0942デフォルトの名無しさん2007/01/20(土) 03:36:26
その感覚がわからない
0943デフォルトの名無しさん2007/01/20(土) 06:45:06
>>938
わざわざHibernateをHibernateとして使うメリットはないと思う。
0944デフォルトの名無しさん2007/01/20(土) 09:05:47
>>943
CriteriaとかLock付きのloadとかって結構いいなと思うんだけど
みんなそーでもないのかな。
0945デフォルトの名無しさん2007/01/20(土) 09:34:12
基本はJPAの範囲でやっておいて、CriteriaとかHibernate独自の機能欲しいときだけEntityManagerからHibernateSessionとってくるほうがよさげ。
0946デフォルトの名無しさん2007/01/20(土) 09:36:45
特に、エンティティの定義は、Hibernate Annotations使うよりはJPAの定義にしておいたほうがいい気がする。
0947デフォルトの名無しさん2007/01/20(土) 11:45:33
>>943
逆にHibernateなのにわざわざJPAを使うメリットは?
標準だから?w
0948デフォルトの名無しさん2007/01/20(土) 15:31:39
ツールと資料と技術者かな。

いままでHibernate使っててノウハウあるなら、勝手にやって。
0949デフォルトの名無しさん2007/01/20(土) 15:32:01
FreeMarkerがVelocityに勝ちきれないのと同じように
既に手をつけたものが用途に納まりきるなら、他のを使うことは馬鹿げている
JDBCひとつでやってきた奴がこれから始めるならJPA
色んなORMを使い続けている奴がいたらそいつもJPA
残りは今までどおりでいい
0950デフォルトの名無しさん2007/01/20(土) 16:36:20
FreeMarker が Velocity に勝ちきれないのは別の理由だろう。
0951デフォルトの名無しさん2007/01/20(土) 17:24:54
>>948
資料と技術者で現時点で優位に立っているとは思えない。
これからだね。
0952デフォルトの名無しさん2007/01/21(日) 11:30:36
NetBeans5.5は標準でJPA対応していてすげーな
JPA対応していれば自由に実装をかえることができるのもよろしい

Hibernate固有の命令はつかわずにHEMだけできるだけ使うのが正解かと
サーブレットだってコンテナ依存コードは出来るだけ書かないのと同じ
0953デフォルトの名無しさん2007/01/21(日) 15:47:16
さすがに、JPAのAPIだけでまかなうのは厳しい
0954デフォルトの名無しさん2007/01/21(日) 18:13:23
>>953
ナニが足りない?
0955デフォルトの名無しさん2007/01/21(日) 18:25:43
簡単なところだと、エンティティ定義の@NotNullとか。
0956デフォルトの名無しさん2007/01/21(日) 19:56:48
>>955
Hibernate Validatorのことか…
ちとレイヤが違うって気がするな。
マッピングだけなら@Column(nullable=false)
0957デフォルトの名無しさん2007/01/21(日) 22:39:37
JPAだとfindと同時にLockって出来なかったと思うんだけど、
それってみんな不便と思わないのかな。
(PUBLIC DRAFTの頃だけかもだけど)

コレ出来ないと
find(SELECT)→lock(PKだけでSELECT FOR UPDATE)→refresh(SELECT)
ってな感じでやらないと真っ当にロックした値にならないように思える。
楽観的ロックは例外飛んじゃうからそれはそれで嫌だし。
0958デフォルトの名無しさん2007/01/21(日) 22:50:02
O/R Mapping の比較はそれ用のスレでやったらどうか。
0959デフォルトの名無しさん2007/01/22(月) 11:05:27
いいんじゃない?
Springネタの投稿ないんだから。
0960某スレ1672007/01/22(月) 12:50:02
んではSpringネタを投下。Spring Remotingって使ったことあるヒトいます?
Eclipse RPCと組み合わせてる記事見つけてハァハァしてまつ(苦笑)
http://www.devx.com/Java/Article/31763/0/page/1

これは(上手く動けば)かなり使い物になるのではないでしょうか?
今までS2Daoが使いたいがためにSeasarを学習していたのですが、今までの学習コスト全てを投げ捨ててSpringするかもしれません(-_-;
0961デフォルトの名無しさん2007/01/22(月) 13:29:17
Spring Remotingは詳細がわからんから運用としてはなんともいえないが
JAX-WS/EJB3ともろにかぶる仕様だな

あとサポートとか考えるとSWT単体はあってもRCPとの組み合わせはまずない
業務系ならSwingのほうが便利だしな
0962デフォルトの名無しさん2007/01/22(月) 13:35:37
Spring Remotingは使ったことないでつが、
>今までS2Daoが使いたいがためにSeasarを学習していたのですが、
>今までの学習コスト全てを投げ捨ててSpringするかもしれません
には共感しまつた
0963デフォルトの名無しさん2007/01/22(月) 14:39:21
S2DAOはJPAでいいかなぁという気がする。
でもSpringRemotingも通信部分と割り切るのもいい。
汎用性ならJAX-WSかな。

でも純正のJavaEE実装もかなりよくなったし、ベストの可能性もある。
EJB3はDI化され、永続化はJPA、XMLまったくかかなくてリモートアクセスまでできるのもいいんだよなぁ。
HTTPがフロントエンドにこなくてもいいのならそのままEJBを使えばいいし、前面にだすならJAX-WS。

ところでspring2.0はフィールドインジェクションできるようになってる?
セッターとかコンストラクタとかは非常に使い勝手が悪いので邪魔。本当はXMLも自動生成されるといいんだけどね。
0964デフォルトの名無しさん2007/01/22(月) 15:11:39
>S2DAOはJPAでいいかなぁという気がする。
おでも最近そう思い始めてる。
S2DaoいいんだけどSeasar前提だとちとつらいケースあるし。
JPA基本で対応できない部分はJPA実装固有の機能で逃げるという気持ちになりつつある。
0965某スレ1672007/01/22(月) 16:45:58
お返事どもっす。


>>961
所謂「リッチクライアント」としてはそうかも。
Eclipse RPCはクライアント側のアプリケーションを構築するフレームワークという意味合いが強いと思う。
クライアント側でどれだけ複雑な処理をやるか、ということで

Eclipse RPC
 ↓
SWT
 ↓
Ajax(GWTはどーなんだろ?)
 ↓
すっぴんのWebアプリ

なんて階層になるのでは、などと思ってまつ。
JavaにこだわらなければFlexあたりも中に割り込んでくるのでしょうがね。
JAX-WSは名前も知りませんでした。ありがとうございます。早速調べてみます。


>>962-964
ORMスレでも書いたのですが、結局1:Nマッピングや複雑なビューの生成は自分で書くしかない、って思ってしまうんですよ。
とりあえずはDbUtilsやSpringJDBCを手早く身に付けておいて、続きはJPAというふうにしたほうがいいかな?、と思っています。
そーするとSeasar2を学習する意味が無くなるのですが……それでもSeasar2の自動コンポーネント登録/自動アスペクト登録にはまだ魅力を感じています。ありゃ便利です。
人はこうやってSeasarの重力に魂を引かれていくのですね(笑)
0966デフォルトの名無しさん2007/01/22(月) 17:10:50
>>964
実際のところJPAでもネイティブなSQL発行できるのでそんなに問題はないと思う
どのみちファサードパターンでユーザー側はDBの存在を意識させないようにしてるし、JDBC直でもなんでもいいし

>>965
RPCだと覚えるのが多いわりに、情報がないので問題がでたとき対処ができない
業務で使わないのならいいかもしれないけどね
同じフレームワーク使うならSwingベースのNetBeansプラットフォームのほうがまだ楽

どちらもでかすぎて最適解ではないとおもうけど
クライアントサイドはフレームワークで縛れるようなコードなんてほとんどないよ

JAX-WSはJAX-RPCの後継でWEBサービスのJavaEE5の一部
アノテーションを使うことにより手軽にサーバーが用意できる
それがなんとJavaSE6に搭載されたおかげで標準APIだけでクライアントのコードを書くことが出来るために
一気にクライアントサーバーのAPIとして注目の的となる

最後の段落の最初のほうは意味がちとわからん
後半はEJBもXML書く必要は一切なしだし、セッターとかも用意する必要ないし、Seasar2使うときもS2Tiger使っておくのが吉かも
0967デフォルトの名無しさん2007/01/22(月) 17:27:00
重箱の隅だけど、RPCじゃなくてRCP(Rich Client Platform)ね。
Eclipseファンデーションから、RMI絡みの新しいフレームワークが出たのかと思ったじゃないか。
0968デフォルトの名無しさん2007/01/22(月) 19:21:54
>>962
Spring Remotingは同じく知らないが、
S2RMIと比べてどの辺が使いやすいのか教えてくれ。
http://s2rmi.seasar.org/ja/index.html
09699622007/01/22(月) 19:47:10
>>968
Spring Remoting使ったことないおでに何故S2RMIとSpring Remotingの比較をせよと?
S2RMIも使ったことないのにw
0970デフォルトの名無しさん2007/01/22(月) 19:48:18
>>966
> それがなんとJavaSE6に搭載されたおかげで標準APIだけでクライアントのコードを書くことが出来るために
> 一気にクライアントサーバーのAPIとして注目の的となる

それだけじゃ無理だお
JDKに最初から入ってるのにCORBA流行ってないお
0971デフォルトの名無しさん2007/01/22(月) 19:56:39
コブラきたーーー(ちがっ)
0972デフォルトの名無しさん2007/01/22(月) 20:04:45
JavaSE6なんて当分遊び人しか使わないしな
0973デフォルトの名無しさん2007/01/22(月) 20:15:56
そういいながらJ2SE5.0についていけない人を何人も見ました・・・。
JavaEE5にもついていけない人は多いのだろうか。

JAX-WSはWSDLからのクライアント生成を徹底しているからクライアントにわたるクラスがなにか意識しないでもいいのがすごいな。
SpringRemotingはクライアントとのやりとりはインターフェースでやるのかな。

SpringRemotingと比較すべきなのはどちらかといえばHTTPを使うS2Axisのほうだとおもう。
ただ、S2Axisって名前がよくないなー。Axisなんてのに依存するのはよくねーよ。
0974デフォルトの名無しさん2007/01/22(月) 20:35:13
つまんねえマッピング(JPA)のミスで3時間無駄にした・・・orz
0975某スレ1672007/01/22(月) 21:09:29
お返事どもっす

>>966
多少前後しますが……えと、ORMスレ読んでました?(^^;
私あちらで「どーせ1:N関係には多かれ少なかれビジネスロジック絡んでくるんだから、
1テーブル/1レコードをそのまま扱うDAO/DTO作って、1:Nの関係扱う(ある程度ビジネスロジックを内包した)ファサードで纏めちゃえばいいぢゃん」とか書いてたんです(苦笑)
単に設計がまずいだけかもしれませんけどね(^^; 自作DAOしこしこ作ってた駄目エンジニアの戯言です。

で、前段。確かに、奥のほうの情報はあまりないんですよね>Eclipse RCP
とりあえず使えるようにする情報くらいまではそこそこ出てきているんですが、何か起こったときにコワいぢゃん、というのは、確かにあると思う。

EJBか……2で挫折したんですよねー、三年ほど前に(^^;
S2Tigerは(もしこのままSeasarするなら)もちろん使うつもりです


>>967
フォローどもっす。素で間違えてました(苦笑


>>968-973
CORBAは全盛期の遥かな昔にチロっと甞めました(苦笑
つーか、そのものずばりのS2Remotingってのが先月出てた……(^^;
http://s2remoting.seasar.org/ja/index.html
0976デフォルトの名無しさん2007/01/22(月) 21:22:36
>>975
そのビジネスロジックの絡んだ1:Nってのがあいまいすぎてわからない

S2TigerつかってるならそれはEJB3.0とほぼ同じだよ
@EJBってフィールドインジェクションとXMlで面倒なのは一切なし
JavaEE5に準拠していればJPAもコネクションプールからDIしてくれるからDB接続等は意識していない

技術的なEJB2との互換性はほぼゼロ(お互いに呼べるけど)だからEJB2ってのと3は別物だと思っていいよ
EJB3.0はSeasar2+JPA(O/Rマッパ)内蔵で非常にシンプル
開発においてSpringやSeasar2より敷居が低いのにはまじで驚ろくはず
0977デフォルトの名無しさん2007/01/22(月) 21:27:04
そこで JBossSeamなんですよねw
0978デフォルトの名無しさん2007/01/22(月) 21:33:19
>JPAもコネクションプールからDIしてくれるから
いまいちわからん
0979デフォルトの名無しさん2007/01/22(月) 22:33:10
>>976
> S2TigerつかってるならそれはEJB3.0とほぼ同じだよ

つS2Tigerで@EJBできるからな
ttp://s2container.seasar.org/ja/ejb3.html
0980デフォルトの名無しさん2007/01/22(月) 22:34:15
ファサードってなによ?w
0981デフォルトの名無しさん2007/01/22(月) 22:43:27
この前魔界に帰ったな
つか、このスレ九州くせぇw
0982デフォルトの名無しさん2007/01/22(月) 23:02:01
>>973
ついていきたくてもWASが対応するまで無理
JavaSE5だって去年やっと対応したが現場じゃこれから
今年こそはアノテーション使いたいよw
好き勝手使える人は気楽でいいよな
0983デフォルトの名無しさん2007/01/22(月) 23:04:43
>>980
複数の呼び出しを一まとめにして呼べと言う
GOFのデザパタ中でもっとも面白くもなんともないパターン。
0984デフォルトの名無しさん2007/01/22(月) 23:13:34
>>980
facade
俺にはファケードとしか読めねぇと思ったが
フランス語らしくCの下に髭みたいのが生えてる文字が正式らしい。
0985デフォルトの名無しさん2007/01/22(月) 23:19:43
>好き勝手使える人は気楽でいいよな
classicなものを使い続けられる人の方が気楽なのでは?
0986デフォルトの名無しさん2007/01/22(月) 23:22:15
980はファサードという単語の意味が分からないんじゃなくて、975のファサードの存在意義が理解できないんじゃねーか?


みんな975みたいなことしてんのか?
ビジネスロジックを内包したファサードってなんだよ?
DTOでもなくドメインモデルでもないクラスってなんだ?
0987デフォルトの名無しさん2007/01/22(月) 23:25:35
>>985
新旧問わず自分で選んだものを好きに使える人は気楽
0988デフォルトの名無しさん2007/01/22(月) 23:31:09
>987
気楽という意味がわからん。


0989デフォルトの名無しさん2007/01/22(月) 23:32:37
お気楽極楽
0990デフォルトの名無しさん2007/01/22(月) 23:34:39
公務員的エンジニアの方が気楽だと思うけどな・・・
0991デフォルトの名無しさん2007/01/22(月) 23:38:01
ところでさっきから出てる Spring Remoting てのは HttpInvoker に限らない話?
当方 Spring Remoting の RMI なら使ったことありました。
本来ならスキーマコンパイラ走らせたりいろいろ面倒なところ、
ビーン定義でサクっと動くのはとても楽。
Javaの世界に閉じてるなら RMI で良いよって感じです。
Java外も絡むならWebServiceかな。

にしても Spring WebService がなかなか Release にならんですね。
ていうか、O/X Mapping から Relaxer の項目消されてるし・・・
0992デフォルトの名無しさん2007/01/22(月) 23:49:26
S2JMSが一向に正式リリースされる気配が無いので
Springに転向したおいらが来ましたよ。
0993デフォルトの名無しさん2007/01/22(月) 23:50:21
>>978
EntityManagerのDI

>>979
同じことが出来るなら人材確保やメンテ考えて標準APIのほうがいいからね
0994某スレ1672007/01/23(火) 01:34:22
んと、まず謝っとく。スレ違いスマソ>ALL

>>986
まぁ、所詮は30台後半でも実装メインで食ってるしがないIT土方の寝言ではありますが(^^;
ただ、はぶさんの「FKかっこわるい。そのへんも全部『○○関係テーブル』って名前でDBに入れとけ」ってのも、なんか違うような気もしないでもない。


>>991
んと、昨日買ってきたばかりの「Spring2.0入門」によると、HessianとBurlapも使える……と、書いてある(^^;
ただ、「ふつーはHttpInvokerでいいんぢゃね?」とのこと。
0995デフォルトの名無しさん2007/01/23(火) 02:26:01
>994
お前が言ってる事も違うような気もしないでもない。
焦点も内容も。

OOPしてないんだろうなきっと。
してないならしてないで構わんのだが、DTOとビジネスロジックの切り分けぐらいはしておいたほうが良いと思うぞ
0996デフォルトの名無しさん2007/01/23(火) 07:50:29
>>993
EntityManagerのDI を「コネクションプールからDI」ってのは
「お父さんとお母さんが結婚したら子供が生まれる」ってぐらい短絡的。
途中のすごく重要なところが抜けている。

DIされたEntityManagerはJDBCコネクションプールとは直接関連しない。
0997デフォルトの名無しさん2007/01/23(火) 10:44:05
>>996
同じ意見。
説明が下手というか、理解していないだろうね。
簡単なサンプルプログラムで試してみて簡単簡単♪って感じで、
実プロジェクトで使っているわけでもなさそうだし、
実プロジェクトで導入できるか評価するといったレベルで使ったわけでもなさそう。
@ITやThink ITなんかの記事読んで、知ったかってとこかな?
0998デフォルトの名無しさん2007/01/23(火) 10:46:19
>>996
おれも思った。
おれはDAO(JPA)のテストする時、コネクションプールなんて設定してないぜw
0999デフォルトの名無しさん2007/01/23(火) 10:49:27
>>996
私もそう思いました。
Spring2.0入門のJPAの章にあるサンプルでもコネクションプールは使っていませんね。
それに「コネクションプールからDI」って本当に意味がわかりません。
DIってどういう意味で使われているのでしょうか。
1000デフォルトの名無しさん2007/01/23(火) 10:53:03
同意が多いと自作自演に見えてくる2ch脳な俺
10011001Over 1000Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。