Java Spring Frameworkを語るスレ

1 名前：デフォルトの名無しさん mailto:sage [04/02/23 00:51] www.springframework.org/ 乱立するフレームワークと競合するプロトコルの嵐のなかで、 リスクの高い決断を余儀なくされているJavaデベロッパ、プ ロジェクトマネージャに対する福音です。 語るべし。 620 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 10:29:59 ] そんな難しいものじゃないし、画期的な機能に満ち溢れているわけでもないよ。 ただ単に便利なツールでいいのだと思うけど。 便利なBeanFactory、それで充分だよ。 おまけで付いてくる付属品はけっこういいよ。 AOPもそうだし、ORMやらmailやらが楽チンに扱えるのも嬉しい。 S2でもSpringでもどっちでもいいけど、これがない世界には戻りたくないね。 EJB3があれば不要という話もあるね、GabinKingが主張しているように。 でもSpringを通してEJB3を使った方がより簡単、そういう機能が出てくるって予想してる。 621 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 10:36:16 ] というか、普通のTomcatで動かせて面倒なパッケージング不要なEJB3、みたいな感じになると思う。 622 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 10:36:44 ] 追伸：煽るワケじゃないが、Springごときを理解できない方が EJB3を使いこなせるとは思えない。Annotationの裏で 起こっている出来事を多少は理解している必要はある、って 認識の元の考えだけど。 623 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 10:58:46 ] Springってかなり裏方的な働きだから、単体ではよさがわかりにくいんだと思う。 EJB3でも、単にORマッピングだという認識で、なんだか裏側で勝手に結びつけてくれるという感じになるんじゃないかな。 624 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 16:27:03 ] EJB3 って来ると思う？ Java ソースにアノテーション埋め込むのと 設定ファイルに外出しされてるのと どっちが疎結合か考えたら EJB3 は退化してるとしか思えない。 625 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 18:56:40 ] アノテーションで疎結合じゃないという話は、すでに時代遅れだし、EJB3が来ないと思うなら、別の部分で批判しないといけない。 626 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 19:05:38 ] 簡単に理由をいえば 「疎結合のためにアノテーションを排除して、なんの意味がある？」 627 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 20:42:36 ] ﾌﾟｹﾞﾗ おまいらどうせ来年にはAnnotationに文句垂れてると思うよ、飽きっぽいから。 628 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 21:45:25 ] >>627 いや、それはそれで良いんじゃねぇの？ 不満がなければ技術革新なんてねぇさ。 629 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 21:58:43 ] Annotationの仕様には不満があるけど、Annotation自体はとても気に入ってるよ。 630 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 22:25:06 ] Springで簡単なWebアプリを作るサンプルがあるサイトしらない？ WebApplicationContextを使って云々みたいな。。。 631 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 22:28:53 ] Struts使った方が楽だからねぇ・・・ 632 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 22:53:59 ] AnnotationとEnumの組み合わせが好きだな XDocletとは違って定数を指定できるし、引数の型チェックも出来る 633 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 02:02:54 ] StrutsよりもJSFをもう少し簡単にした物を使いたい 634 名前：デフォルトの名無しさん [2005/12/13(火) 09:39:22 ] >>630 ほらよ www-06.ibm.com/jp/software/websphere/developer/j2ee/lightweight/ www5f.biglobe.ne.jp/~webtest/myapptutorial/index.html https://appfuse.dev.java.net/ https://equinox.dev.java.net/ 勧められるのは、ビジネスロジックレイヤ内にサービスレイヤを 作ってるヤツ。（Facadeかけてるやつ） とりあえずIBMのヤツを熟読しろ。 635 名前：教えてください [2005/12/13(火) 21:35:54 ] 左クリックを使用できないようにjavaScriptを組んだつもりでしたが、機能しません。 どこが間違ってるのかご指南ください。 問題のＨＰ　urei.ojaru.jp/top.htm フレームを使用してますが　 Ｉｍａｇｅｓ→***のリンク→左使用不可ページ　となってます。 ***　のページ　左使用不可ページ直リン防止script 左使用不可ページ　左使用不可script このようにしたのですが･･･････ﾏｲﾘﾏｼﾀ もうどうしていいのか分りません 636 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 22:01:21 ] >>635 はスレ(板？)違いの上に、マルチ 637 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 10:05:47 ] 板違いというより、基地外 638 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 02:08:32 ] Spring.NETの方はどうですか？ 同じ？ 639 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 13:48:47 ] >>638 Spring.NETは基本的なDI・AOPの機能は既に実装済み。 DB、トランザクション、WEB等の機能はまだ開発中みたいだな。 だけど、正直.NETでDIは使う気にならないな。 640 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 13:07:47 ] >>639 何故？ 641 名前：デフォルトの名無しさん [2005/12/24(土) 12:10:09 ] ActionSupportを使ってStrutsとSpring連携させてるんだけど このクラスのテストケースをstrutstestcaseを使って書こうとした時に Actionから呼び出すBeanを変えてテストケース書きたい場合 Bean定義のXMLを変えるしか方法がない？ テストケース側からビジネスロジックの注入を書けると楽なんだけど、、、 642 名前：デフォルトの名無しさん mailto:sage [2005/12/25(日) 01:54:24 ] 自分で注入しちゃったら？ 643 名前：デフォルトの名無しさん mailto:age [2005/12/26(月) 01:34:51 ] Struts + Sringでエ○画像掲示板つくってみました。 Spring入れたほうが動作は安定して早くなりました。 644 名前：デフォルトの名無しさん [2005/12/26(月) 11:56:02 ] >>642 その方法がわからないんだよう ポインタなぞあったら教えてぎぶみー 645 名前：デフォルトの名無しさん mailto:sage [2005/12/28(水) 07:47:52 ] Spring2.0って機能面ではどう変わったんですか？ 646 名前：デフォルトの名無しさん mailto:sage [2005/12/28(水) 07:55:33 ] >>644 セッターインジェクションの場合 setXxx(value); フィールドインジェクションの場合 xxx = value; で注入できますｗ 647 名前：デフォルトの名無しさん mailto:sage [2005/12/28(水) 14:12:36 ] >>645 設定ファイルがXML Schemaベースになってる。 648 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 12:31:25 ] Important new features include: * Simplified, extensible XML configuration * Powerful new Spring AOP features and AspectJ 5 integration * Asynchronous JMS facilities enabling message-driven POJOs * Spring Portlet MVC, a MVC framework for JSR-168 Portlets * ... and much, much more これって設定ファイルが結構変わるのかな？ 個人的には三番目がようやくと言った感じ。 JmsTemplate はいろいろ思うように行かなくて (非同期受信なし、リソースを開放するタイミングが制御できないなど) 結局新たに作成したものを使った。 JndiTemplate があればどうにかなった。 649 名前：デフォルトの名無しさん [2006/01/08(日) 02:38:17 ] フレームワークの議論ばかりしていて実際にハイレベルな パフォーマンス＆拡張性が要求される現場では役に立たない 方々乙かれさまです。 650 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 03:19:20 ] どこでも役に立たない>>649よりはマシだけどな。 651 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 03:40:27 ] >>635>>637>>649 652 名前：デフォルトの名無しさん mailto:sage [2006/01/10(火) 15:18:00 ] 普通なら釣りなんだろうが現場見てると 本気でそう考えてるｵｻｰﾝがたくさん居て死にそうになる。 さすがに起動時だけは遅いが、一度起動してしまえば 速度が気になったことはないな。 拡張性については具体的な例を挙げて欲しいな。 どういう要求が出た時にどういう対応をしたのかを。 653 名前：デフォルトの名無しさん [2006/01/11(水) 03:07:47 ] HibernateDaoSupportを使う場合にQuery#setFirstResults(int)やsetMaxResults(int)を 使うにはどうすればいいかご存じの方はいませんか? getHibernateTemplate().find* ではQueryオブジェクトを渡せないし。。。 getSession()して自分で処理するしかないかな。 Spring 1.2.6 です。 654 名前：デフォルトの名無しさん mailto:sage [2006/01/11(水) 11:24:00 ] >>653 HibernateCallback 655 名前：653 mailto:sage [2006/01/11(水) 22:34:55 ] >>654 return getHibernateTemplate().execute(new HibernateCallback() { public Object doInHibernate(Session session) { // クエリ投げて結果を返す } } って感じですね。マニュアルにも載ってました。ポイントありがとう。 656 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 20:54:23 ] ttp://pcweb.mycom.co.jp/news/2006/01/20/346.html > Drools 2.5 BETA 2において提供されている拡張モジュールはdrools-decisiontables、 > drools-dotnet、drools-examples、drools-groovy、drools-ide、drools-io、drools-java、 > drools-jsr94、drools-python、drools-smf、drools-smftest、drools-spring、 > drools-spring-examples、drools-spring-jdk5。ベースとなる藻ジュースはdrools-base、 > drools-core、drools-core-3.0。 Springにも対応しているらしいルールエンジンだが、なんだかベースが不味そうだ。 657 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 21:14:58 ] >>656 「藻ジュース」(・∀・)ｲｲ 658 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 10:27:33 ] いや飲みたくはない…… 659 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:26:19 ] 今、新しいｱﾌﾟﾘ作るんで、まあ流行のSpringと扱い慣れているStrutsでと思っています。 まずはｱｰｷﾃｸﾁｬを決めるために、いろいろサンプルを作ってみてるんですが、質問です。 Struts&Springの連携で、代表的なのは 　1) ActionSupport 　2) DelegatingActionProxy 　3) DelegatingRequestProcessor の3つだと思うのですが、2) or 3) で決めかねています。 1)はせっかくなんでつまらないのでﾎﾞﾂ。 残るはDelegatingActionProxyとDelegatingRequestProcessorですが、 機能的にどちらが良いのか分かりません。 どちらかと言えばActionを継承させてBaseActionを使っていたことが多いのですが、 RequestProcessorの方が上位ですよね。 アプリケーションは到って小規模なんでどちらでも同じだと思いもするのですが、 考慮すべき点や拡張性の点等、ご助言･苦言を頂けないでしょうか。 非常に基本的な質問で恐縮ですが、 660 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 23:34:09 ] たいくつでつまらない技術が一番強い。 661 名前：659 mailto:sage [2006/01/24(火) 11:18:42 ] >>660 確かに、ごもっともだと思います。 実はこれまでの開発ではSpringを使う機会もあったのですが、 見易さ、改修性の高さ、開発規模から ServiceはInterfaceを使わずに実装しました。 (さすがにDAOはiBatis使って分けましたが) それに比べ、今回は10年前にCで作った参照のみのアプリの更新で 時間的な余裕もあるので遊びたいと思ってます。 APIも読んでみたのですが、XDOCLETを使うか、また宣言で問題があったら、 といった使い分けの程度しか理解できませんでした。 みなさん、どのような使い方されているのでしょうか、教えて頂けるとありがたいっす。 662 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 13:57:58 ] >659 (1) と (3) は Struts に変更があったら、思い切り引きずられそう。 TilesRequestProcessor が出ようが新規に Action が発明されようが 涼しい顔して DelegatingActionProxy でラップするのみの (2) が好きですね。 (ていうか (2) しか使ったことないですけど。) その分設定ファイルは煩雑になるわけですが。 自分の分かりやすいと思える方法でやるのが一番かと。 小規模でそれほど寿命も長くないのであれば、(1) も手っ取り早くていいと思いますよ。 XDOCLET は思ったほど便利じゃないと言うか、 開発の間に試行錯誤してると、結局手で書いたほうが速かったでした。 ↑これは設計がまずかっただけかも知れません。 663 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:17:11 ] >>662 Actionベースはやはり分かり易いですよね。 人数が多いそれなりの規模なら、間違いなくActionProxyでいくと思います。 いくつかサンプル作ってみたのですが、3種類の感想は ActionSupport -確かに楽だけど、Springの楽しさは十分に味わえない気が。 　でも実装はまんまActionなんで、いたって簡単。 　しかもプログラマの質がそれなりなら、自分入れて3人位いれば 　中規模まで行ける気がする。 ActionProxy -実質これがStruts&Springの標準でしょう。 　至って堅牢なシステムが訳分からん害虫と一緒でもテストファーストで 　スムーズに作れそう。 　しかもこれまでのStrutsの資産も十分に生かせるんじゃないでしょうか。 RequestProcessor -Controler以前の処理をガチガチにやるのであれば、やはりRequestProcessorだと 　思います。 　が、幾分硬すぎる気が。大人数のRUPには向いているかな。 自分ごときが作るシステムはそれほどクリティカルじゃないし、ユルイと思うのですが、 まあ当たり前、と言った感想でしょうか。 今回はActionProxyからやってみようと思います。 時間もある分、新しい人も多いんで。 また進展したら報告します。　いらんか。 664 名前：デフォルトの名無しさん mailto:sage [2006/01/25(水) 12:22:51 ] ＞また進展したら報告します。　いらんか。 最近スレが過疎ってるからチラシの裏でも問題ないかと。 ＞訳分からん害虫 でかいところが素敵なフレームワーク作ってるかと言うと そんな仕事にありつけたことが一度もないのは運が悪いんだろうか。 665 名前：659 mailto:sage [2006/01/25(水) 22:18:20 ] >>664 なかなか難しく厳しい問題です、拡張性･メンテナンス性を含めた機能美で言えば。 確かに誰がやったん?ってひどいのもありますが、現状では仕方ないかとも思っています。 1つはレガシーのためです。 やはり遺物であっても今から見ればあほあほなRDB設計であっても どうしても引きずらないではいられません。 例えばホストシステムの特定部分をWebに置き換える際、レガシーのデータやインターフェースは その他のホストのためにつないでやらないといけません。 おかげでせっかくのDAOも、結局は???になってしまいがちです。 これまで私も挑んだのですが砕け散りました。 もう一つは、企業にとってみればシステムが構築されれば後は減価償却の対象でしかありません。 本来3ヶ月かけて作るべきものであっても即興で1.5ヶ月でつくれば評価されてしまいます、 掛けたくないのは人件費な訳ですから。 もちろんこんなシステムの維持のコストは高いです。が、トップの方々には見えてきません。 ユーザーからの機能追加要望があった、といえば、それなりのコストであれば通ってしまいます。 海外拠点との情報連携なんてつけてやれば大喜びです。 (フェーズ毎に見積もりきちんととって開発も難しいのが現状ですから・・・) と、過疎板でうだつのあがらん社内SEが独り言ってみました。 666 名前：デフォルトの名無しさん mailto:sage [2006/01/25(水) 22:53:35 ] 664ですがマ板向きな話題になりそうなのでこの件はクローズ。 脱線させてごめんなさい。 667 名前：デフォルトの名無しさん mailto:sage [2006/01/29(日) 00:03:48 ] すいません、Spring.NETの話題もここで良かったりします？ 668 名前：デフォルトの名無しさん mailto:sage [2006/01/29(日) 09:45:51 ] わかんない。 けど、とりあえず書いてみれ 669 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 10:23:30 ] >>659 ＞うだつのあがらん社内SE お前様はオレですかｗ 疑問に思ったことを二つ。 ＞見易さ、改修性の高さ、開発規模から ＞ServiceはInterfaceを使わずに実装しました。 何故だよ？　facadeした方がP層から見たときに理解しやすいし、 実装ロジックを意識しないで済むと思うのだけど。あと例えば 君がAPI定義して、君の手下が実装する、なんて作業も スムースになると思うのだけど。 あと、その場所にSpringのTransaction制御は適用してるの？ それとも君達でゴリゴリ書いているの？ そこがSpringの一番美味しい所だと思うのだが。 670 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 10:24:23 ] ＜連投＞ ＞流行のSpringと扱い慣れているStrutsでと思っています。 扱い慣れているとはいえ、何故に死滅が確定している 現verのStruts？　同じ社内SEの立場として言うが、 それって将来に禍根を残すんじゃないの？ 特に、struts-taglibを使うのは忌むべきことじゃないのか？ 高度にクリティカルじゃなくてもいいなら、素直にJSFを 採用すりゃいいじゃん。もし、strutsじゃなきゃ人材を 確保できねぇと言うなら、せめて org.springframework.ui.velocityパッケージの研究を してから決定した方がいいんじゃないの？ 671 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 12:13:28 ] 死滅とかはNG Wordに入れてる人も居るから避けたほうが吉。 JSF はもう少し枯れてからの方が良くない？ 今のところ、Velocity でやっちゃうのが一番直感的に思う。 672 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 12:24:21 ] うちで使ってるアプリケーションサーバーはJSPしか動かねぇ Servletすら使えない 673 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 15:42:57 ] 釣りには屈しない 674 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 09:47:13 ] おぉ、まだ居る方が。 >>669 ServiceのInterfaceについては、いかに害虫がｵﾌﾞｼﾞｪｸﾄ指向を知らなくても ｵﾌﾞｼﾞｪｸﾄ指向らしいJavaになるか考えてこうなりました。 まずあの方達はｸﾗｽを上手く切り出せないんです、最初は。 で、下手にInterfaceやって使いまわしなんて考えると開発中の手入れが 恐ろしいことになり、ある意味好き勝手にやってもらいました。 で、DAOについてはﾒｿｯﾄﾞが明確なんでInterface切ってやってもらってます。 iBatisを使ってるんですが、こいつだとDAOの中のみでTransaction制御できるんで 助かります。 これだと統合ﾃｽﾄ中にこっちでｸﾘﾃｨｶﾙな部分がすぐいぢれるんで楽なんですよ。 675 名前：659 mailto:sage [2006/02/01(水) 10:14:07 ] 書き忘れですが、674 = 659です。 Strutsについては、JSFでの置換えも検討しましたが、 今回、自分以外はJavaでWebやるの初めてなんですよね。 やはりﾌﾞﾗｳｻﾞからRequestをServletで受けて、というのを実感 し易いのはStrutsかなぁ、と思います。 JSF、VBちっくにﾄﾞﾗｯｸﾞ＆ﾄﾞﾛｯﾌﾟでできてしまうんで、最初からこれだと 裏の理解が薄く後々に生きない気がします。 それと社内SE的にはもう少し枯れてからで良いかなと、正直思います。 Taglibについては、個人的にこれ以上覚えられるかー、ということで beanとlogicにのみ制限しています。 まあ多少beanを拡張はしていますが。。。 個人的には、Struts → JSFで行きたいなと、Viewについては。 676 名前：669 mailto:sage [2006/02/01(水) 10:53:44 ] >>659 ＞DAOの中のみでTransaction制御 これって複雑なことをやろうとすると破綻しないかい？ 複数のテーブルを更新するのもDaoのメソッド単位になる、 従って肥大したDaoImplを書かざるを得なくなる、という原因で。 オレのやり方だとこんな感じだ。 <ServiceLayer> public void deposit(Account account, Money increasedMoney){ 　　accountDao.update(account); 　　revenueDetailDao.insert(account, increasedMoney); } で、トランザクションはあくまでserviceLayerに置く。つまり上の depositメソッドに対してPROPAGATION_REQUIREDを設定する。 オレはさらに、dao層、上の例ではaccountDao.updateと revenueDetailDao.insertに対しては PROPAGATION_MANDATORYをかけている。 これによりserviceLayerを通さずにDaoに触ったら即座にアポーン。 君の「DAOの中のみでTransaction制御」だと、上の二つの メソッドを一つにまとめないと原始性を維持できないのでは？ 勘違いだったらｽﾏｿ。 677 名前：659 mailto:sage [2006/02/01(水) 12:13:46 ] >>669 DAO単位で考えれば原始性を維持できない可能性は仰る通り存在します。 でも、実際の使用で考えれば、多少複雑なﾃﾞｰﾀはﾕｰｻﾞに紐付いているわけで、 2重ログインを防げば、問題無しという訳です。 美しくないことは、確かですが。 Springでのﾄﾗﾝｻﾞｸｼｮﾝ管理は、まだ読んだだけですけど、実装も含めｽﾏｰﾄですね。 ﾄﾗﾝｻﾞｸｼｮﾝ属性なんか、いかにも楽できそうで。 DAOは何を使われてるんですか? 今回はHibernateが親和性も高く、情報も多いんで使おうかと思ってます。 678 名前：669 mailto:sage [2006/02/01(水) 13:12:05 ] う〜ん、オレにはそれはチョト怖く感じる。 更新が途中で落ちる可能性なんてゴロゴロしてるワケだし。。。 （オレには納得いかんが）落ちる可能性を完全無視するとしても、 その場合は最低でもペシミスティックロックで組まんとイカンと 思うのだけど。。。 頼む、トランザクション管理層をserviceLayerに持ち上げとくれ。 Spring使えばチョチョイのチョイだ。 iBATISは好きだぉ。 679 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 16:24:19 ] >>669 仰ってることが分かってきました。 自分が話しをごっちゃにした予感です、害虫さんと自分の立場を。 害虫さんのﾄﾗﾝｻﾞｸｼｮﾝ管理は、はっきり言って、信用してません。 で、問題があった際にDAOとServiceを引っ張って考えるのはしんどいんで DAOについてはiBatisのAutoCommitにして、自分はServiceに集中できるように している、という話です。 読み返してみると、確かに訳分からん話してますね、自分。 そういえば、SpringとベストマッチなDAOって何でしょ? iBatisもいけるようだとﾈｯﾄに載ってた気がしますが、やはりHibernateですかね? 他に面白いのないでしょうか。 680 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 20:56:14 ] HibernateはDBを一から設計するっていうならおすすめ 既存のDBがからむならiBatisの方が無難だとおもう 害虫さんがいてiBatis学習コストが気になるっていうなら Spring JDBCでもいいんじゃない？ 681 名前：デフォルトの名無しさん mailto:sage [2006/02/02(木) 01:17:25 ] >>675 ＞Taglibについては、個人的にこれ以上覚えられるかー、ということで ＞beanとlogicにのみ制限しています。 Strutsでやるんなら最低限必要なStrutsタグはhtmlタグのみで、後はJSTLで置き換えるのがお勧め JSTLはJava EE5に含まれることが決定しているし、JSFも1.2からはJSTLと連携出来るようになる 682 名前：デフォルトの名無しさん mailto:sage [2006/02/02(木) 01:36:23 ] お勧めとかではなく、beanとかlogicを使うべきではない、という感じだな。 683 名前：659 mailto:sage [2006/02/02(木) 10:15:36 ] >>680 既存DB、IMSもRDBもわんさかあるんで、これまではiBatisだったんですよね。 ｵﾌﾞｼﾞｪｸﾄﾍﾞｰｽでのDB考えるなら、Hibernateというｲﾒｰｼﾞは確かに強いですよね。 そんな幸せな開発はやったことありませんが。 >>681、682 z/OS中心の製造業社内SE的には、Webのプレゼンテーション層については過渡期に 感じるので、枯れ果てた技術で十分かなと思います。 新しい技術を入れても今後ﾒﾝﾃする人が大変なだけですよ、うちのような環境では。 JDKにしても既存のものは1.4.Xが限度で、5にすることなんてありえません。 ぶっちゃけ、手間の割にﾒﾘｯﾄがあんまり考えられません。 それよりも新しいWASには5を導入する方向で考えると思います。 個人的にはJSFの熟成を期待しつつ、ちょっと複雑になりそうだったらﾘｯﾁで、 と行ければ良いなぁ。 ・・・今はこんなこと考えている自分が、ちょっと嫌。 Javaを始めて勉強してた頃はｵﾌﾞｼﾞｪｸﾄ指向に感動し、新技術ﾏﾝｾｰだったのに。 他に居ないのかな、こんな方。 684 名前：デフォルトの名無しさん mailto:sage [2006/02/02(木) 11:17:28 ] >682 beanを使うべきじゃないとは言っても、 messageはなかなか避けられないような。 685 名前：669 mailto:sage [2006/02/02(木) 11:31:58 ] おいおい、そんな後ろ向きになるなよ。 新技術に対する感動を忘れたらオレらの仕事はつまらなく なるばかりだぜ。つーか、今でもspring・iBATIS・hibernateって やってるんだろーが。何でviewだけそんなに野望を失うのさ？ struts-taglibは、数年後には非推奨API（あるいはそれに準じた 無体な扱いを受ける立場）になるんだぜ？　君は後進に 非推奨APIのメンテをさせる気かい？ JSF怖くないってｗ　つーかあれ便利だぞ。少なくてもstrutsに 比べりゃね。なんつったて同じ作者の二番煎じなんだから。 JSF自体がDI持ってるからSpringとの組み合わせもし易いしね。 練れてなくて意味無い所で苦労を強いられるのは認めるけど。 な〜んて書きながら、オレ自身もJSFマンセーには なりきれないのだけどね。初期の頃に宣伝されたリッチ クライアント対応とか全然進んでねぇし。（JDNCは実質 ポシャったみたいね）　早いとこJSPの呪縛から抜け出して 欲しいと思っているのに、なんか全然別の方向に逝こうと しているみたいだし。。。 愚痴ｽﾏｿ 686 名前：デフォルトの名無しさん mailto:sage [2006/02/02(木) 11:44:00 ] JSFも悪くないと思うけどね、まだ出来たてのせいか ちょっとこなれてない感じ。 EL式とかアレだし。 sunのより高機能なんでmyfaces使っても、バグが結構あって DataTableとか微妙な挙動をする場合がある。 1.2待ちかな 687 名前：デフォルトの名無しさん mailto:sage [2006/02/02(木) 13:02:24 ] >>684 messageは使うね。 >>686 2年もたってるのに、出来立てはないとおもう 688 名前：659 mailto:sage [2006/02/03(金) 12:37:57 ] >>669 Viewも野望だけはあるんですけどね。 ただWebだと、JSFにしても色々あり過ぎて、決め手に欠けます。 それにお偉方の説得材料が足りません。 もう暫くおとなしく待って、淘汰されてから選んで良いかな。 Viewはお偉方にも分かってしまうんで、ここ以外は、好き勝手やれるんだけどねぇ。 689 名前：デフォルトの名無しさん mailto:sage [2006/02/03(金) 13:49:52 ] 正直jsp2.0で十分な気が 690 名前：デフォルトの名無しさん mailto:sage [2006/02/15(水) 15:03:14 ] Hibernate3初心者ですが、ちょっと教えて下さい。 many-to-one のﾏｯﾌﾟで、もし該当ﾃﾞｰﾀが存在しなくても怒られない方法、 知りませんか? 例えば <class name="item"> <id name="id"/> <many-to-one name="bid"/> </class> <class name="bid"> <id name="id"/> <pro name="amount"/> </class> これで from Item item left join fetch item.bid　をやって、 取得したリストを表示させると、bidを取得できなかったitemの item.bid.amountをgetすると、 LazyInitializ E org.hibernate.LazyInitializationException TRAS0014I: 次の例外がログに記録されました。 org.hibernate.LazyInitializationException: could not initialize proxy - the owning Session was closed と、ｱﾎﾞﾝです。 session閉じて分離ｵﾌﾞｼﾞｪｸﾄになってんだから、良いじゃん、 と思うんだけど、教えて下され。 691 名前：デフォルトの名無しさん mailto:sage [2006/02/15(水) 15:11:12 ] >>690 スレ違い pc8.2ch.net/test/read.cgi/tech/1134701684/ 692 名前：690 mailto:sage [2006/02/15(水) 15:56:38 ] >691 ｽﾏｿ 693 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 11:35:44 ] 保守、というか1.2.7記念。 694 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 12:03:36 ] EJB3.0 のどこが DI なのかと思い始める今日この頃。 695 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 12:49:55 ] つまり、勉強不足？ 696 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 23:10:38 ] @EJBアノテーションによるフィールドインジェクションだが？ 697 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 23:40:25 ] まぁ勉強不足なのは確かだが。 結局クライアントコードに依存性を書いてる辺りが、 確かに従来のJavaの文法じゃないけど アノテーションと言う名前のただの lookup じゃん、とか。 (DIとは関係ないが)@Statefulも アノテーションと言う名前の implicit な interface になっただけで 同じことをするのに書法のバリエーションが増えただけで Perl のガラクタ折衷主義を思い出したり。 698 名前：デフォルトの名無しさん mailto:sage [2006/03/08(水) 22:01:48 ] "アノテーション使ってるからDIじゃない"っていいたいの？ interfaceがメソッドに付けれますか、と。 "ただのlookup"ではないしな。 結局アノテーションどうこうとゴネてるやつって、変化を受け入れれないだけなんだよな。 699 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 01:38:51 ] クライアント側でリソース名を明示的に書いているから DIとはいいがたいと思ってます。 ＞"ただのlookup"ではないしな。 どんな嬉しさがあるか、教えていただけないでしょうか。 煩雑な記述が減る程度しか思いつきません。 ＞interfaceがメソッドに付けれますか、と。 @Stateful はメソッドに付かないと思うけど。 700 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 03:37:13 ] >>699 > クライアント側でリソース名を明示的に書いているからDIとはいいがたいと思ってます。 つまり、DIをわかってないと。 701 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 13:01:15 ] そっか。DIの定義が変わったのか。 702 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 22:20:05 ] >>701 変ってないだろ。 君が勘違いしてるだけ。 703 名前：デフォルトの名無しさん [2006/03/11(土) 15:16:19 ] 2.0になってどう？ 近い将来でseasar使うか2.0使うか迷ってるんだが、 Spring側の利点が見つからない・・・ 両方つかってみたけど、seasarだとXMLをかなり省けるから 楽なんだが・・・ 誰か意見ください。 704 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 13:14:45 ] >702 DIって、クライアント側で明示的にリソース指定した部分が コンテナが注入するようになって素敵だよって流れだと思ってたんですが。 で、勘違いのない本当の定義とは？ >703 利点が見つからないならSeaser2使えば良いかと。 とりあえずXMLが省けることは多分大した利点にならんよ。 705 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 21:56:40 ] 横槍ｽﾏｿ >>704 そもそもEJB3のDIは「明示的にリソース指定」はしないぞ ＞とりあえずXMLが省けることは多分大した利点にならんよ。 その根拠は？ 書かなくて済むのであれば書かないに越したことは無いし XMLのメンテナンスだって馬鹿にならない 706 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 23:15:36 ] >>704 DIの最低限の定義は、自分でインスタンスをとって来ないで、よそから注入してもらうこと。 @EJBアノテーションつけたとしても、それなりのコンテナ使わない限りなにも影響はない。 そのままSpringやSeasar使えばそれなりに注入される。 707 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 10:32:53 ] DIに関して705氏と706氏の意見で納得。 確かに自分でインスタンスとってきてるわけではないね。 俺はとってくる情報が書かれてることそのものが嫌いなんですが これはDIとは関係ないってことですね。 >その根拠は？ autowire 使えばそれなりに記述量は減るけれども 曖昧さが増えてかえって混乱を招くだけだった、との経験から。 Seasar2だと違うのかも知れない。 適当なこと言ってごめんなさい。 それにしても盛り上がらないスレですね。なんでだろ。 708 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 18:46:23 ] 一部雑誌や新しいもの好きが飛びついてるだけで 現場ではほとんど使われてないから。 709 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 19:36:29 ] はい、飛びつきました 710 名前：デフォルトの名無しさん [2006/03/14(火) 22:14:33 ] うちでは全部SpringかSeasar使ってるが、世間ではそうなのか？ トランザクションに関してはとても楽だが 711 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 17:34:47 ] >>707 いったん使い出せば、通常の範囲では質問もなにもないし、特に話題がないからかもね。 712 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 17:52:50 ] ｲｲﾅｰ うちで使ってるｽｹﾞｰ高いアプリケーションサーバーは jspしか使えない 713 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 21:47:24 ] そりゃないんじゃね〜の？ 714 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 22:14:35 ] >>712 BroadVision One-To-One 以前はC++しか使えなかった。マジで。 715 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 22:14:55 ] 713宛てだった 716 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 22:30:54 ] 「Portal,Commerceの価格は1CPUで810万円からとなっております。」 ΣΣ（ﾟдﾟlll） 717 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 00:03:31 ] そういやあ、WebObjectsも昔は７５０万とかしたよなあ。。。。 718 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 00:05:24 ] 製品カタログ見ても何をするものなのかが分からん。 719 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 02:13:23 ] JSPしか動かないTomcatみたいなの ショボいDBのラッパーとかユーザー管理とかビジネスルールのライブラリとかがいっぱい付いてる あと やたら高い 720 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 03:57:55 ] うちの会社で出してるゴミコンポーネントも945万円するお。 1年で1個売れれば万々歳だって。

---

---

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

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