△△もっとStrutsの良さを教えてくださいSession5

1 名前：デフォルトの名無しさん [2006/12/30(土) 18:05:08 ] Apache Strutsフレームワークについて語るスレ 前スレ △△まだまだStrutsの良さを教えてくださいSession4 pc8.2ch.net/test/read.cgi/tech/1109465052/ 52 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 07:36:28 ] >>51 ブラウザはWEBアプリ専用のソフトウェアじゃねえんだよ！！ 53 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 08:06:32 ] >>49 今のところRubyの方が遅いのは事実だが、 いいハードを買うかクラスタを増やすかすれば必要な性能は達成できる。 Rubyは生産性が高い（例のRailsの「Javaの10倍」ね）ので、開発コストを減らした分の金で 元は十分以上に取れる。というかハードなんて人件費に比べれば安いし。 ってのがRuby屋の言い分だと聞いた。 立場は逆だが、>>50の言うような「Java登場時にJavaプログラマが言ってたこと」に似てるな。 54 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 10:15:01 ] >>51 つAjax DBから取得したデータをJSON変換して、後はJavaScriptに扱わせる。 SwingのTableModelみたいなことは、今でもやろうと思えばできる。 Swingと同じで、Ajax主体でGUIを扱うFWがまだ無いけど 55 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 12:15:04 ] >>53 Javaちらっと触っただけなんでよく知らないんですが、 性能面とかで大規模な案件に耐えられる代物なんですか？ どうしてもしょせんインタープリタ言語ってイメージが取れません・・・ 偏見ですかね？？？ 個人的にはOOで設計した方がいいぐらいの大きさのプログラムなら もう慣れているC++で書いた方が手っ取り早いし、 本当にささっと作るだけならVBやるかなーって感じです。 今のところJavaの方が遅いのは事実だが、 いいハードを買うかクラスタを増やすかすれば必要な性能は達成できる。 Javaは生産性が高いので、開発コストを減らした分の金で 元は十分以上に取れる。というかハードなんて人件費に比べれば安いし。 ・・・なるほど、たしかに似てるなｗ 56 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 21:51:33 ] >>55 Amazon.comってWeblogicだそ？ 57 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 21:52:49 ] あ、なんでもない忘れてくれｗ 58 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 21:55:01 ] >>56 そうなのか? perlって記事もあるけど。 neta.ywcafe.net/000492.html 59 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 21:58:56 ] 相当前に聞いた話だからもうperlなのかも？ 60 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 22:56:58 ] >>54 Ajaxってどうなん？ 所詮JavaScriptじゃろ？ ていうかなんでJavaAppletがほったらかしなんだか判らんｗ 61 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:20:28 ] さっさとJSFに乗り換えた方が幸せになれると思うんだが。 再利用性などというマヤカシに捕らわれてるのが移りが遅いな。 実際に再利用できるものは汎用Util化されてるだろうしFWはなんでもいいはずなのに。 62 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:28:41 ] strutsで再利用と言えば、 Actionを連鎖させて途中のアクションをフィルタ的に使ったりすることもあるけど 実際は、1画面1アクションで作られてることが多いみたいだね。 明確にM-V-CとするよりもM-VCのほうが、効率いい場合もあるし。 63 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:31:16 ] >>62 ＞1画面1アクション そういう使いかたした事ない 64 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:36:42 ] >>62 多いっていうか、そういう風にしか使い道が思いつかないんだろ 65 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:36:58 ] うちのプロジェクトも原則は1画面1アクションだよ Action連鎖すると修正時の影響範囲がわかりにくくね？ しょせん、Actionなんてコントローラだし対して再利用性を求めてもしょうがないような 66 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:42:27 ] Actionでやるべき事と、業務ロジックを分離した時、Actionでやることはほとんど共通化できるんだけどね 67 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:47:03 ] っていうか、業務ロジックを呼び出すActionの振る舞いなんてﾐﾝﾅ同じじゃん 68 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:51:43 ] 普段はどちらかというと、1画面につき2Actionかな？ ただ、入力→確認→完了とか、複数ページにわたる入力みたいな いわゆる「画面フロー」の間は画面間で1Actionだな。 JSFだと、「1Action」が「1アクションメソッド」に変わる感じ？ 69 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:54:46 ] 1画面1Actionにすると表示前準備とリクエスト処理が混在してわかりにくい。 あちこちの画面から呼ばれるような処理だと、さらにゴチャゴチャ。 70 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 00:15:25 ] ActionってCommandパターンだからと思って、最近は１URL１Actionにしている 以前は１画面毎にDispatchAction使ってたが、あまり意味ないし使いにくいのでやめた ロジックはサービス層のクラスにまとめて共通化してるので、 Action自体はパラメータの受け渡しぐらいしかやらないし 画面単位ではまとめないけど、初期化処理とか検索処理とか編集処理とか 似たような処理をするActionを継承でグループ化したりはしている 71 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 18:10:10 ] Action連鎖させるなんて絶対にやめるべき。 値の持ち回りはSessionにぶち込んででしょ？ 大量にバグが出るし、修正が発生した時地獄を見るよ。 コミットするような処理した後 一覧か業務フローのトップの画面を表示するActionにリダイクレトする、 とかならやるけど、これはもう処理の流れが切れているから。 OO中途半端にやってる人（俺含めて）を見ていつも思うんだけど 再利用って言葉の一人歩きがひどすぎないか？ 72 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 18:20:35 ] sessionじゃなくてrequestにぶち込むだろ普通。 sessionの使用禁止のプロジェクトもあるし。 どうでもいいけど、sessionの使用禁止ってのは無しにしてほしい。 ロードバランサ入れたときに別サーバに振り分けられるからって言うけど ロードバランサにsession維持機能あるんだから有効にすりゃいいだけじゃん。 73 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 18:23:42 ] NECダイレクトのサイトは、コンテナに頼らず自前でセッション管理してるっぽい？ URLに入ってるセッションIDらしき文字列がちょっと見慣れないんだが。 そういう方法もありかね。 74 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 18:25:24 ] 対話の質によるけどな。 フルGCの発生原因は中途半端な寿命のオブジェクトが在ることだし。 75 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 18:27:27 ] >>73 URLリライティングだろ、Tomcatでも使えたはず 76 名前：デフォルトの名無しさん [2007/01/06(土) 18:46:34 ] Action連鎖はわけわからなくなるな。。 validationとか絡んだら無限ループなる。 77 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 20:24:05 ] >>76 atamawaruikaradayo(pu 78 名前：デフォルトの名無しさん mailto:sage [2007/01/08(月) 07:59:12 ] >Action連鎖 大昔から否定されてきたのをいまだ言ってるやつがいるのか・・ 少しはググってみたら、どうだ？ 79 名前：デフォルトの名無しさん mailto:sage [2007/01/10(水) 08:48:22 ] >>78 ttp://civic.xrea.jp/2006/02/28/strutsecii/ この人なんかは推奨してるみたいだけど、否定する理由っていうのはなに？ 80 名前：デフォルトの名無しさん [2007/01/10(水) 20:17:35 ] Strutsインアクションでは Actionを連鎖したくなるのは、Actionにビジネスロジックを書いているからだ！！ ビジネスロジックをサービス層に移せばActionの連鎖なんか必要ないはずだ！！ って書いてました 81 名前：デフォルトの名無しさん mailto:sage [2007/01/10(水) 20:23:21 ] >>80 そういう問題ではないな 82 名前：80 [2007/01/10(水) 20:30:46 ] >>81 そやな。。俺も自分でおもた 83 名前：デフォルトの名無しさん mailto:sage [2007/01/10(水) 20:51:58 ] forwardによる画面遷移、かつ同一ActionFormを利用する場面では Actionの連鎖を避けるべきだが、 リダイレクトによる画面遷移がOKな場面で、 かつ両Actionクラスで同一のActionFormを使わないような場所で、 画面表示前にビジネスロジックの実行が必要な場合は Actionの連鎖を使っても良いと思うよ。 人が否定したからと言って鵜呑みにする奴もアレだし。 Actionの連鎖がどういう動きをするのかをちゃんと理解して 使い分ければいいんじゃないかな。 84 名前：デフォルトの名無しさん mailto:sage [2007/01/10(水) 21:48:24 ] 独りよがりでやる分にはいいけど、 他人との合同開発や仕事でそんなもの出すなよ？ 85 名前：デフォルトの名無しさん mailto:sage [2007/01/10(水) 21:57:23 ] 厨乙。 86 名前：デフォルトの名無しさん mailto:sage [2007/01/11(木) 00:54:45 ] 俺は、登録してから、初回の表示と同じようなことする場合に、 初回表示用のアクションに連鎖させてる。 登録アクションには登録する処理しか書いておらず、 登録後に表示されるページの情報を作る処理は、連鎖先のアクションで作っている。 87 名前：デフォルトの名無しさん mailto:sage [2007/01/11(木) 01:04:20 ] >>86 アリだと思うよ。 88 名前：デフォルトの名無しさん mailto:sage [2007/01/11(木) 01:15:19 ] 何でもそうだけど、頭使って適切に使いこなすより、一律に同じ方法で統一しちゃう方が簡単だもんなぁ。 89 名前：デフォルトの名無しさん mailto:sage [2007/01/12(金) 00:08:26 ] 馬鹿の水準に合わせて開発すると、時間と体力ばかりくっていいこと無い 90 名前：デフォルトの名無しさん [2007/01/13(土) 12:26:10 ] すいません初心者で恐縮ですが Strutsの初心者向けの学習本で良いのありますか？ 91 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 16:10:56 ] なんか最近、自作の俺様専用フレームワークが最強のような気がしてきた。 92 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 16:33:44 ] >>91 気のせい。もしくは、限定された環境でのみ最強。例えば開発者があなただけとか。 93 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 16:34:12 ] >>91 それは皆が通ってきた道だな 94 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:15:52 ] バリデータとコンバータが全てのFWで共通化されたら俺は平気で移る。 95 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:17:56 ] commons-validatorの事じゃなくて？ 96 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:20:40 ] strutsのバリデータって他フレームワークに簡単に持って行けないもん？ リクエストパラメタをBeanUtilsとかでBeanにセットしてvalidateってできないのかな。 97 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:27:37 ] commons-varidator commons-beanutils あとRequestUtilsクラスとかパクりゃいんじゃねーの？ 98 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:36:32 ] Webフレームワークを使う理由はバインディングしかないからね。 テンプレート機能だとか画面遷移だとかはフレームワーク作者のオナニーに付き合ってるだけ 99 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:38:47 ] 便利だけどね 100 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:54:24 ] JavaのWebフレームワークを一から作るくらいならStrutsつかっときゃいーと思うがの Strutsを使いやすいように拡張した方がな 101 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 01:45:43 ] オライリーのJakarta Strutsクックブック ってどうですか？ 102 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 01:49:45 ] Strusの本読んだ事ね 103 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 01:57:32 ] 二日ほど他人のソースとテックスコアの記事読んで適当に実践に使ったから本は読んでない。 104 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 02:08:24 ] Ja-Jakarta Projectのページ ttp://www.jajakarta.org/struts/ 105 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 10:00:49 ] >>101 あまり読んでないけど、JSTL関連の章は役に立った。 おかげでlogicタグとbeanタグからはおさらばして、Struts上でJSTLとELをフルに利用できるようになった 106 名前：デフォルトの名無しさん mailto:sage [2007/01/16(火) 14:27:59 ] strutsって重くないですか？ 107 名前：デフォルトの名無しさん mailto:sage [2007/01/16(火) 14:42:45 ] >>105 レスありがとうございます。オライリーのサイトで目次を見ると、自分にはいろいろ 参考になることがありそうなので、買って読んでみます。 108 名前：デフォルトの名無しさん [2007/01/16(火) 21:41:15 ] >>106 使わないよりは重いな 109 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 20:15:47 ] 今回初めて使ったけどこれひどいね Strutsタグのエラーとかstruts-config.xmlの記述間違いの際のエラーとか のメッセージが不親切すぎてデバッグできやしない 110 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 23:03:37 ] ﾌﾟ 111 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 23:24:07 ] >>109 WTPのJSP・XMLエディター使うといいよ 112 名前：デフォルトの名無しさん mailto:sage [2007/03/05(月) 00:12:36 ] >>109 まぁ確かに不親切だとは思うけどね。 IDEのサポートちゃんと受けてる？ 転職したら秀丸でソース編集とかしている俺から見れば・・・ 113 名前：デフォルトの名無しさん mailto:sage [2007/03/05(月) 00:55:45 ] ＥＸＣＥＬファイルで定義してstruts-config.xml、validation.xml、フォームBeanを自動生成してます。 114 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 23:59:17 ] >>113 画面の仕様書から バリデーションとフォームの生成まではやった。 ただしバリデーション定義はS2Strutsのアノテーションによる方式。 あれ結構自動生成と相性がいいと思う。 struts-configのExcelからの生成ってどうですかね？ いまいちもとのExcelシートのイメージができないです。 115 名前：デフォルトの名無しさん mailto:sage [2007/03/09(金) 01:02:39 ] 1ワークブック＝1モジュール 1シート＝1Form 　　　　＝1Action 　　　　＝1リソースファイル（忘れてた） フォームの定義はValidation定義も併用 フォームBeanも自動生成 ネスとしたBeanのValidationも対応 global-exception等は別に1シート 116 名前：デフォルトの名無しさん mailto:sage [2007/03/09(金) 01:03:51 ] 要するに1ワークブック＝１struts-config.xml 117 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 01:15:23 ] >>116 そのExcelファイルくれ。 118 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 02:50:48 ] >>117 残念ながら、Excelだけではだめなのだ 自動生成ツールが必要なのだ 119 名前：デフォルトの名無しさん [2007/03/14(水) 19:20:37 ] struts 2.x が正式リリースになっているな。(2/27) だけどこのスレではぜんぜん話題になってないな。 120 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 19:29:22 ] >>119 Strutsって名前だけで、中身はStrutsともApacheとも何の関係もないからな。 121 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 19:58:47 ] たしかに　2.x は WebWork と統合、 Shale もあるし、 ひさしぶりにやる側としては、もうわけわかめです。 122 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 12:38:45 ] この間終ったプロジェクトじゃまだstruts1.1だったしなぁ。 またstrutsやるとしても1.x系だろうしな。2.xは手がだせんかも。 123 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 12:50:54 ] 2.xを使ってる話なんて聞いたことがない。 2.xは元々Strutsではないから、 バージョンアップというよりまったく別フレームワークへの乗り換えになる。 1.xを使っているのなら、1.3.5はなかなか有用。 モックオブジェクトが用意されたテストケースがあったり RequestProcessorのカスタマイズが柔軟だったり。 124 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 13:02:09 ] じゃあなんでsturtsなんて名前つけたんだ？ ぶっちゃけ、2.xがまったく別物ってんなら余計混乱して そのまま「strutsｵﾜﾀ」ってなりそうな気配がﾌﾟﾝﾌﾟﾝしてるんだが… というか、struts projectの人間は2.xが本来やりたい事だったんだ！ って言ってる様にも見えなくもないな…どのみち衰退の道か 125 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 15:08:48 ] strutsどころかapacheでさえないプロジェクトから移管されたものだからなぁ。2は。 126 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 16:08:32 ] 結局フレームワーク使うとこういうことになるんだよ。 それで終わったフレームワークで作られたシステムを 新人にメンテさせる鬼先輩になるんだ、おまえらは。 127 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 16:37:37 ] >>126はバカだなぁ 128 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 20:05:34 ] >>126 独自仕様てんこ盛りの自社製FWのメンテよりはいいだろう？ 129 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 21:39:10 ] >>128 >>126は自社製FWとかではなく、常に１から作るンだろ？ そういうほうがわかりやすいと思うヤツが多い事は事実 130 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 22:10:40 ] >>129 そういうのはフレームワークが古くなるどころか、 作った奴がいなくなるだけで混乱に陥る。 古かろうが、Strutsのように普及したフレームワークを使う方が ノウハウを持った奴がどこかにいるだけまだマシ。 131 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 23:39:40 ] Struts1.X系でお茶を濁しつつ、JavaEE5サーバが出回ったら JSF1.2にメインの開発は移行すればいいと思う。 GlassFishもJBossもGeronimoもベータ版が出たし、そろそろ動かせるよ 132 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:01:21 ] Glassfishは正式リリースじゃないかｗ JBossはもうReleaseCandidate。 Tomcat6はStableリリースだから、もうJSF1.2の環境はOKだ。 でも実際はEclipseWTPやNetBeansがTomcat6対応しないと使いにくいな。 133 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:06:55 ] >>129 それわかりやすいかぁ？ 作った人間いなくなったら恐ろしいことになるよ。 どうせドキュメントも残さないで消えていくんだろうし。 134 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:19:40 ] >>132 GlassFishは現在V2がリリース間近 V1はJavaEE5SDKとして出すためのものだったが、 今回はフルスペックのアプリサーバとして出す NetBeans5.5.1でGlassFishV2に対応してる。 EclipseWTP用のPluginもGlassFish側で用意してるけど、WTPがまだJavaEE5対応してないな 135 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 01:18:21 ] JavaEE５なんていらねーよ 136 名前：デフォルトの名無しさん [2007/03/29(木) 20:08:06 ] struts-confg.xmlの内容をエクセルに記録して XML出力とかいうツールどっかにおちてない？ エクセルは設計書にできたらなおOK。 137 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 22:42:01 ] >>136 せんせーすとらつこんふぃぐがえっくすえむえるなんですがー 138 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:27:01 ] >>137 Excelで画面遷移とか定義して、そっからstruts-config.xml出力してくれるマクロとかツールが欲しいって意味なんじゃないの？ 139 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:25:45 ] 子ノードも無限に作れるし、属性もいくつあるかわからんし XMLをExcelで表現するのは無理があるだろ 140 名前：デフォルトの名無しさん [2007/03/30(金) 13:50:46 ] すみませんが、初歩的質問です。 Strutsの良さの一つとして、Actionクラスの存在がよく挙げられています。 Actionクラスはサーブレットよりずっと軽量なので、１つのActionServlet（の 派生クラス）と多数のActionクラス（の派生クラス）に構築されたコントロー ラは、従来のサーブレットに比べてパフォーマンスが良い、というのです。 しかし疑問なのですが、そのActionクラスの遷移先はJSPで、そして結局JSP一 つがサーブレット一つになるのですよね？こちらのパフォーマンスは問題にな らないのでしょうか？ なんとなくですが、JSPを使い続けているのに、コントローラだけActionクラス を主体にしても、パフォーマンスはあんまり変わらない気がするのですが、ど うなのでしょう？ ということで、 ・従来のサーブレットのパフォーマンス ・ActionサーブレットとActionクラス ・JSP ・（JSPの代わりに）Velocityテンプレート それぞれの実行性能をご存知の方、お教えいただけないでしょうか？ 141 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 14:46:53 ] >>140 ActionとActionServletのおかげでパフォーマンスが向上するなんて、 聞いたこともない。出典は？ Actionクラスの目的は、Commandパターンの導入とstruts-config.xmlによる 画面遷移の宣言的制御にあるじゃなかったっけ （それが成功しているかは別の話だが）。 この辺でも読んでみて。 ttp://wiki.apache.org/struts/StrutsBenefits しかし今頃になってStruts初心者か。今でも人気あるんだね。 142 名前：140 mailto:sage [2007/03/30(金) 15:45:56 ] >>141 > ActionとActionServletのおかげでパフォーマンスが向上するなんて、 > 聞いたこともない。出典は？ すみませんが、出典は分かりません。 以前にStrutsを使ったことがあって、そのときに何かで読んだのですが、1回だ けでなく、あちこちでその内容を聞いたように思うのです。 それにしても、聞いたこともありませんでしたか。ちょっとショックです。私 の勘違いだったのかなあ。 143 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 15:58:31 ] 基本的にフレームワークは骨組みにいろんな仕事やらせるんだから プレーンで作るより重いよ。体感的には変わらないけど。 144 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 00:42:23 ] Actionの存在が良さとは思わんが・・ 俺が思うStrutsの良いところは・・ ・HTTPパラメータがActionFormとして明確になる ・画面遷移とコントローラの依存が疎になる ぐらいだと思う。 パフォーマンスが良くなるなんて聞いたこと無い。 145 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 03:29:56 ] >>142 完全な勘違いだよ。 ActionServletやらで色々な処理が間に入っているんだから 素でServletを書くより早くなるわけないじゃん。 といってもこの程度のオーバーヘッドでパフォーマンス云々語るのは かなりアホなことしゃべってると思った方がいいよ。 146 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 03:52:13 ] >>142 あちこちで聞いたって職場でかい？ ちょっと身の振り方考えた方がいいんじゃないかね。 揶揄して言ってるんじゃなくて そんな一笑に付されるような俗説がまかり通るってのは 全体のレベルが低い証拠だと思う。 自分の今後にとってもプラスにならないよ。 147 名前：140 mailto:sage [2007/03/31(土) 19:41:57 ] どうもお恥ずかしい話ですみません。私の勘違いだったようです。社の人から 聞いたのではなく、雑誌かWEBの記事だったと思うのですが、誤読したのでしょ う。 しかし、実行速度は下がるにしても、他のメリットは無いのでしょうか？ サーブレットに比べてアクションクラスは ・インスタンス生成のコストが小さい ・メモリの占有量が少ない という特徴があったりしないでしょうか？ もしあるとしたら、たぶんそういう記事を私が誤解したのだと思うのです。 まあ実質的にはメリットに上げるほどの差ではないのかもしれませんが。 148 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 00:53:58 ] >>147 あるとしても、鼻毛抜いてダイエットするくらいの効果しかない。 HttpServletの実装はコンテナ依存なので、ひょっとしたらActionとの差が大きくなる コンテナがあるのかもしれないが…HttpServletの実装が重いコンテナなんてヤダ。 というか、仮に軽くなっても、struts-config.xmlやvalidator.xmlをメモリに展開する分、 別の分でメモリ食ってるはず。 ま、世の中には、無意味または時代遅れなバッドノウハウを語る低脳ライターが割といるので、 そういう連中の記事を読んだんじゃないかと思う。 「メソッドにfinal付けて高速化」とか、「同じローカル変数を使い回してメモリ使用量を削減」とか言う奴と一緒。 最近笑ったのはこれ。 ttp://www.atmarkit.co.jp/fjava/javatips/168java053.html ライターなんて、下はこの程度ですよ。 149 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 01:05:37 ] >>148 これはひどいｗ 150 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 01:09:12 ] >>148 こ、これは・・・ こんな糞記事で原稿代もらえるのか・・・ 俺も何か書こうかな。。。 151 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 19:49:01 ] >>150 期待してるぜｗ 152 名前：デフォルトの名無しさん [2007/04/08(日) 20:42:52 ] >>148 ちびった・・・ｗ

---

---

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

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