[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 10/02 21:59 / Filesize : 215 KB / Number-of Response : 915
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

【DI】Java Spring Frameworkを語るスレ 2.0



1 名前:デフォルトの名無しさん mailto:sage [2007/01/23(火) 10:59:45 ]
前スレ
ttp://pc10.2ch.net/test/read.cgi/tech/1077465099/

公式
ttp://www.springframework.org/

655 名前:デフォルトの名無しさん mailto:sage [2008/04/01(火) 10:59:21 ]
ttp://cubby.seasar.org/ がSpringで使えるようになったらうれしい。

656 名前:デフォルトの名無しさん mailto:sage [2008/04/01(火) 12:35:26 ]
>>655
SAStrutsの方ならSpringで使えるようになる
ttp://d.hatena.ne.jp/higayasuo/20080401/1207016839
> SAStrutsとS2JDBCもSuper Agile Spring上に移植する予定です。

657 名前:デフォルトの名無しさん mailto:sage [2008/04/01(火) 15:50:20 ]
>>654

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

>>653

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


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

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

659 名前:デフォルトの名無しさん mailto:sage [2008/04/01(火) 22:29:08 ]
>>656
4/1だもんな。
それに、Strutsはいらない。

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

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

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

662 名前:デフォルトの名無しさん mailto:sage [2008/04/02(水) 02:46:05 ]
>>660

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

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

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

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



664 名前:デフォルトの名無しさん mailto:sage [2008/04/02(水) 03:11:31 ]
FreeMarker はどうよ?

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

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

666 名前:デフォルトの名無しさん mailto:sage [2008/04/02(水) 04:10:36 ]
>>664

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

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

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

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

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

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

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

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

672 名前:デフォルトの名無しさん mailto:sage [2008/04/03(木) 23:34:53 ]
SeasarってJPAとの相性そんなにいいか?
まずトップがJPAを消そうとしてるように見えるんだが

673 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 00:15:19 ]
>>672
Kuina>>>>越えられない壁>>>>JpaTemplate
簡単な問合せはインターフェース書くだけ
ttp://kuina.seasar.org/ja/user_guide/query.html
複雑ならCriteria
ttp://kuina.seasar.org/apidocs/org/seasar/kuina/dao/criteria/CriteriaOperations.html
SQLサポートも強力
ttp://kuina.seasar.org/ja/user_guide/query.html#SQLによる検索
EntityManager直に使うこともできる。何も隠されてない



674 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 01:17:22 ]
どうでもいいけど、Springスレにまで出張するのは頭おかしいとおもうんだ
スレまちがえてないか?

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

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

675 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 01:40:11 ]
>>674
>672の問いに答えただけだが

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

676 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 02:43:13 ]
何を根拠にSFSBといきなり限定的な話になるのだ

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

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

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

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

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

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

679 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 03:46:27 ]
>>677
コミッタに教えてやれよw

680 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 12:16:26 ]
>>678
拡張コンテキストについて詳しく

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

682 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 13:30:30 ]
>>680
トランザクション境界ぬけたら非管理下におかれるんじゃないの?

683 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 13:31:07 ]
>>681
だった。



684 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 13:50:49 ]
>>682
それ通常の永続コンテキスト

685 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 13:57:34 ]
KuinaもJPAもEJBもスレ違い

「Java⇔RDBのMapping-Frameworkを語るスレ Vol.4」
ttp://pc11.2ch.net/test/read.cgi/tech/1134701684/

686 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 15:00:38 ]
>>684
なら拡張つかうのやめれば?

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

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

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

688 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 19:25:32 ]
>>686の発言はいみふ

689 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 19:35:46 ]
>>688
SFSB使ったことないのかい?

690 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 19:42:09 ]
Swingクライアント+SFSBならWebと紐付け不要

691 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 22:16:02 ]
>>690
揚げ足取りイクナイ

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

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

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



694 名前:デフォルトの名無しさん mailto:sage [2008/04/13(日) 14:25:15 ]
>>693
ロッド・ジョンソンに言ってこい

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

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

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

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


698 名前:デフォルトの名無しさん mailto:sage [2008/04/13(日) 22:13:25 ]
>>693
イミフ

699 名前:デフォルトの名無しさん mailto:sage [2008/04/13(日) 22:32:42 ]
>>693
退場してください

700 名前:デフォルトの名無しさん mailto:sage [2008/04/13(日) 23:00:11 ]
オブジェクト指向万歳!!

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

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

702 名前:デフォルトの名無しさん mailto:sage [2008/04/14(月) 00:02:02 ]
>>701
保守性の高い見通しのよいプログラムには興味あるだろう?

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



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



704 名前:デフォルトの名無しさん mailto:sage [2008/04/14(月) 00:27:49 ]
          ,. .‐'テ'ー、-. .、
        /: : :/ : : : : ヽ : : \
       ! : r‐┴‐-、: : : l : : : :l l
     ,.にニニニニlュュ_l: : : :_l:」__
   /   ,.ィ /"^l ト、  ̄``Tニ>
  /イ,イ / /コ/┐ iヒヘl'ニゝ、   |     言ってみろよ…!
   l/ lイ/l==a゙  ,,=a==:l r=、 |     能書きたれてみろ…
.         l.`ー_)   ー ' |.|h.} |     聞いてやるよ…
       l 「 ___   u |Lノ :ト、
          ヽ ‘ー─‐’ /゙ヽ  |: :「:Tー-
    _,, .-‐'|\  ̄ /   u \| : |:::|: : :
 ‐'' ´: : : : : : |::|: l`:イ       l : j|:::|: : :
 : : : : : : : : :.:|::| : i : ヽ     ノ : ノ|:::|: : :
 : : : : : : : : : |::|: : :\ :`:ー-‐ ': : /: :|:::|: : :

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

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

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

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

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

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

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

706 名前:デフォルトの名無しさん mailto:sage [2008/04/14(月) 00:53:45 ]
      、-‐- 、,. z_
   < ̄       ゝ
  ∠´    /Vヽ    ゝ
∠   ∧/`'  ム,    ヽ   なんや おどれと話をしてると
∠/レ'      ム  _,_  `、
 |   ,.−      ヾ(へヽ ヽ   わいも落ちるとこまで落ちたって
 |/ /ト、 }    ヽV~) )  ヽ    気になるわ…
 \ ヽ ノ 、シ  ,.イ   ヾ '    }
 ,/   `` ー-―- 、  ヽ.   l
 L r っ  _. -‐ォ  )   )\ /⌒ヽ
    (二´-‐_'´ノ    /  ./    〉、
     (二´-‐ ' 、 ` / ,/       / \
      \ヽヽ` / //      /   ヽ
       ` ー 'ヽ/ /        , '       ヽ
          /ヽ. /     /         ヽ

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


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

709 名前:デフォルトの名無しさん mailto:sage [2008/04/14(月) 01:37:38 ]
どうしてそんな結論に至るのかまったく理解不能。

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

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

711 名前:デフォルトの名無しさん mailto:sage [2008/04/14(月) 01:57:09 ]
>>664
FreeMarkerってstruts2が中で使ってた

712 名前:デフォルトの名無しさん mailto:sage [2008/04/23(水) 20:08:53 ]
HibernateもFreeMarker中で使ってるんじゃなかったっけ。

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

微妙にスレチ下げ。


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

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

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



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

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

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


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

715 名前:デフォルトの名無しさん mailto:sage [2008/05/07(水) 18:43:41 ]
>>712
FreeMarkerは開発者が人間のクズ。


716 名前:デフォルトの名無しさん mailto:sage [2008/05/08(木) 01:16:44 ]
>>715
どういうこと?

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

718 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 16:16:06 ]
>>717

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

719 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 17:11:13 ]
>>717
いつの人ですか?

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

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

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

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

722 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 17:44:46 ]
意識しないなんて誰か言ったか?

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



724 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 17:56:51 ]
つまりwicketはだめでJSFは最高というわけですね

725 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 18:01:03 ]
アホか。

726 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 18:26:54 ]
JSFって良いか?
もうRESTな作りできるようになったんだっけ?

727 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 18:39:10 ]
REST厨ってHTMLのstrict厨と同じ臭いがする

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

729 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 22:40:20 ]
技術というか単なる道具とかテンプレートだよな…

730 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 23:38:15 ]
論文がどうだとか言い出すREST厨は嫌いだが
RESTがRIAと相性がいいのは確か

731 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 00:33:59 ]
RIAといってもクライアントがさまざまだからなんとも

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

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

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



734 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 01:54:31 ]
スレ違い
pc11.2ch.net/test/read.cgi/tech/1031149340/

735 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 02:47:17 ]
>>732
だからクライアントしだいだろ?
WSDLによるクライアントの開発の容易さは捨てがたいだろう。

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

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

736 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 15:49:55 ]
好きなものを使えってことで。

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

737 名前:デフォルトの名無しさん [2008/05/14(水) 20:00:58 ]
329 名前:デフォルトの名無しさん[sage] 投稿日:2008/05/13(火) 22:04:29
冷ややかな戦争勃発w
ttp://d.hatena.ne.jp/masataka_k/20080513/1210661500#c

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

343 名前:デフォルトの名無しさん[sage] 投稿日:2008/05/14(水) 02:08:47
とりあえず、保存しといた。
s04.megalodon.jp/2008-0514-0207-34/d.hatena.ne.jp/masataka_k/20080513/1210661500

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 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 22:07:47 ]
擦れ違いかもしれんが、
Jboss seam使っているやついる?

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


739 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 22:16:39 ]
汎用フレームワークの話ならこっちじゃね?
pc11.2ch.net/test/read.cgi/tech/1181063688/

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

740 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 22:35:14 ]
あ、そんなスレあったんだw
サンクス。


741 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 23:02:38 ]
春よコイ!

742 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 18:14:48 ]
>>716
亀レスだが
pc11.2ch.net/test/read.cgi/php/1120519290/34

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

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



744 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 23:26:32 ]
>>743
何を言ってるのかサッパリだわ

745 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 23:34:33 ]
>>743
狂っどる

746 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 23:52:56 ]
>>743
SOAな連中が語るRESTとROAな連中が語るRESTは別物

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

748 名前:あぼーん mailto:あぼーん [あぼーん]
あぼーん

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

750 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 20:16:17 ]
>>749
Hibernateかな。
これが一番普及してそうだし。

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

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

753 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 22:16:53 ]
>>749
DBUtils



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

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

755 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 23:32:44 ]
>>754
JDBCテンプレートがそんなもんだな






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<215KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef