JSF(JavaServer Faces)【.NET死亡？！！！】

1 名前：デフォルトの名無しさん mailto:sage [03/07/26 17:33] スレがないので新しくたてました www.atmarkit.co.jp/fjava/special/jsf01/jsf01.html java.sun.com/webservices/downloads/webservicespack.html 802 名前：デフォルトの名無しさん mailto:sage [2005/11/18(金) 00:02:51 ] DIコンテナってみんな独自だったのがEJB3という標準化によって どこのアプリ鯖使っても動くようになるってのは割と大きいよ 803 名前：デフォルトの名無しさん mailto:sage [2005/11/18(金) 00:09:42 ] EJB3って、HibernateとTopLinkにちょっとでも互換性を持たせるための仕様じゃないの？ 804 名前：デフォルトの名無しさん mailto:sage [2005/11/18(金) 00:51:41 ] EJB3はDIコンテナとしては中途半端だと思う。EJBをDIするぐらいしか出来ないし >>803 その２者を使ってO/Rマッピングの標準を作ったということじゃないだろうか 805 名前：デフォルトの名無しさん mailto:sage [2005/11/18(金) 00:56:08 ] >>795 レスありがとー。 やっぱまだ時期尚早かぁ。 file1.grp.yahoofs.jp/v1/8Jp8Q23h3jyW5zc2F8FdoipQK_wwW7TE5hF5dmuMm-sziRay0zv38zEyvu1WojpHFhXU1bMMCx-jad1WYgmxvmJV4Ug/JSFTips.html ↑こことか見るとサーバーリソースも現行のWebアプリより食いそうだし、 こなれてきてもWebアプリは全部JSF！みたいにはならないかもなぁ。 806 名前：デフォルトの名無しさん mailto:sage [2005/11/18(金) 01:13:55 ] >>805 アーキテクチャや思想としてはStrutsよりもかなりいい感じなんだけどね。 もうちょっとこなれて欲しい。 これからの進化に期待。 807 名前：デフォルトの名無しさん [2005/11/18(金) 12:54:20 ] Sun Java Studio Creatorで業務した人いる? なんか使った感じ、かなり便利だった。 808 名前：デフォルトの名無しさん mailto:sage [2005/11/18(金) 13:18:10 ] JDevelopperもSun Java Studio Creatorも どっちも便利だな。 残念ながら、Eclipseには相当する機能は現時点ではないしな。 809 名前：デフォルトの名無しさん mailto:sage [2005/11/19(土) 18:12:32 ] 結論：Sun One >>>>>>>>> Eclipse 810 名前：デフォルトの名無しさん [2005/11/19(土) 22:17:15 ] >>805 見れないんだけど、何が書いてあるの？ 811 名前：デフォルトの名無しさん mailto:sage [2005/11/20(日) 01:17:28 ] >>810 ごめん。家のPCでYahooにログインしっぱなしだったからそのまま貼っちゃった＾＾； groups.yahoo.co.jp/group/jsf-jp/ ここのブリーフケースの中にあるJSFTips.htmlってファイル。 よくわかるJavaServer Facesのしくみ www.amazon.co.jp/exec/obidos/ASIN/4883732096/ ↑の本書いてる吉田 裕之って人が書いたJSFのTIPS集。 結構詳しいからJSF使うなら読むといいんじゃないかな？ で、ここに「JSFはサーバーパワーが必要」って項目があったんで、そんなんで実際の現場で普及すんのかな？と。 812 名前：デフォルトの名無しさん mailto:sage [2005/11/20(日) 01:36:39 ] >>811 さんきゅ！ 813 名前：デフォルトの名無しさん mailto:sage [2005/11/20(日) 04:28:42 ] >>811 サーバーパワーなんか、ヒューマンリソースに比べれば二束三文 814 名前：デフォルトの名無しさん mailto:sage [2005/11/20(日) 04:31:56 ] 実際の実行環境は、パワーあるマシン使うのが普通なので問題ない 815 名前：デフォルトの名無しさん mailto:sage [2005/11/20(日) 13:47:52 ] 何Wくらいのがお薦めですか？ 816 名前：デフォルトの名無しさん mailto:sage [2005/11/20(日) 13:50:19 ] 1.21ジゴW 817 名前：デフォルトの名無しさん [2005/11/22(火) 20:59:34 ] 死亡したのは.netではなくstrutsだな。 818 名前：デフォルトの名無しさん mailto:sage [2005/11/22(火) 21:42:24 ] >>817 struts現verの死滅は確実。（と、struts開発元も公言） shaleがどうなるのか見ものだね。 個人的にはshaleは「出しゃばりすぎ」との予感してる。 shaleを『軸に』システム組むなんて発想は真っ平ゴメン!! P層のフレームワークは純粋にviewを構築するパーツで あって欲しい。 その点、JSFは、いいセンスしてると思う。実装がこなれて いなくて使い辛いのは認めるけど。 勘違いだったらｽﾏｿ 819 名前：デフォルトの名無しさん mailto:sage [2005/11/22(火) 22:34:29 ] >>818 全面的に同意。 （今の）Shaleは覚えることが大杉。使いこなすのが恐ろしく難しい。 JSFとChainとSpringとTilesと・・・と多数のフレームワークやライブラリの 使い方を全部マスターする必要があるんじゃないのか？と思うぐらい。 JSFそのものは思想・アーキテクチャとしては優れているね。 実装と開発環境がもう一皮むけるのを心待ちにしているよ。 820 名前：デフォルトの名無しさん mailto:sage [2005/11/23(水) 12:32:42 ] >>802 実際はそうなるんだろうな。 純粋なスペック面ではDIやってる連中にはヌルすぎと批判されてるが。 こないだのJavaOneでSeasarの人とか。 821 名前：デフォルトの名無しさん mailto:sage [2005/11/23(水) 14:04:45 ] >>820 Hibernate等のO-Rマッピング技術もまったく同じことだね。 Java Persisence APIによって標準化され、どこでも同じAPIで どこでも同じように動くようになる。 822 名前：デフォルトの名無しさん mailto:sage [2005/11/23(水) 14:22:30 ] JSP/servletとかと同じだよな 結局よほどじゃないかぎりライブラリやフレームワークに依存したコードは書きたくない JSFに関してはもうちっとなんだろうけど creater２見る限り開発は問題なさそうだが 運用環境が頭痛いか 823 名前：デフォルトの名無しさん mailto:sage [2005/11/24(木) 02:27:49 ] creater２いいとかいうが あの自動生成のソースが気持ち悪くて最悪なので どうしても使う気になれない。 824 名前：デフォルトの名無しさん mailto:sage [2005/11/24(木) 23:34:54 ] コンパイル後のバイナリが気にならないように、 自動生成のソースの中身を気にならなくなる時代が来るのかもな。 825 名前：デフォルトの名無しさん mailto:sage [2005/11/24(木) 23:38:28 ] 自動生成部分はいじらないのが普通だろ GUIエディタでもそうだし 826 名前：デフォルトの名無しさん mailto:sage [2005/11/24(木) 23:39:01 ] >>824 そう思う。 アセンブラなどをやっていた人間からするとJavaが既にそういう存在だと思うし。 827 名前：デフォルトの名無しさん mailto:sage [2005/11/24(木) 23:48:53 ] つーか、コンパイラとかアセンブラ自体がすでに（ｒｙ 828 名前：デフォルトの名無しさん mailto:sage [2005/11/25(金) 09:43:37 ] >>826 アセンブラやってた人間ならCの時点ですでに悲鳴上げたことあるだろｗ 829 名前：デフォルトの名無しさん mailto:sage [2005/11/25(金) 15:12:41 ] 開放感でうれしかったけど。 830 名前：デフォルトの名無しさん mailto:sage [2005/11/25(金) 23:25:23 ] Cコンパイラが生成したアセンブラソースのことじゃね？ 831 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 09:48:27 ] 開発ツールSun Java Studio Enterprise 8、無償でリリース − ＠IT www.atmarkit.co.jp/news/200511/10/jsc.html タダで使えるようになったみたいだけど、これのJSF機能ってどうなの？ 楽チン？ 832 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 11:49:07 ] >>831 JSFに特化するなら、Creatorのほうがいいかも 833 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 13:11:08 ] >>831 JSFに特化かどうかというよりも、その両製品は対象ユーザが違う。 JSFのAPIを隠蔽して、完全にグラフィカルな作業環境で開発したい →Creator APIなどをある程度把握して、自分で好きに実装したい →Sun Java Studio Enterprise どんなコードを生成してくれても気にしない。そのかわりにお手軽開発というのならCreator。 そのかわり、大規模アプリケーションを何人ものプログラマでコードを共有するのには向いていない。 システム開発屋が扱うというよりも、ユーザ企業の担当者がちょっとした マスタメンテツールや情報検索ツールを作るのに向いているし、そういうユーザがターゲット。 834 名前：831 mailto:sage [2005/12/04(日) 13:59:46 ] >>832 >>833 レスありがとう。 だとすると、業務で使うとしたらメインはやっぱJava Studioの方になるのかな〜。 Createrはちょっとしたツールとか書く時にはロジックに集中できて便利そうね。 ちなみにダウンロードサイトが英語だったりしてイマイチよく分かってないんだけど、 この2つの「無償」ってのは、商用利用も含めて「無償」で使っていいよ、ってこと？ それとも個人利用の制限あり？？ 835 名前：デフォルトの名無しさん [2005/12/16(金) 13:57:57 ] いつの間にか facelets1.0.4がreleaseされてますよ。 https://facelets.dev.java.net/ 誰か人柱になってくれんかのぉ。 836 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 19:38:38 ] >>835 人柱よろｗ 837 名前：デフォルトの名無しさん [2005/12/18(日) 02:29:30 ] Oracle、ApacheにJSF実装「ADF Faces」を寄贈へ pcweb.mycom.co.jp/news/2005/12/15/023.html 838 名前：デフォルトの名無しさん [2005/12/18(日) 21:19:55 ] 通常のリンクで<to-view-id>にフォワードするのに<from-outcome>に指定した文字列を使いたくて <f:view> <h:form> <h:commandLink action="link"> </h:form> </f:view> と書いてます。 これをもっと簡単に書く方法はありませんか？ 839 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 22:55:32 ] 充分に簡単だと思うけどな・・・・ 840 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 23:04:59 ] JSFじゃなければ<a href="link.jsp">で済むので、簡単だとは思えません。 841 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 23:48:26 ] GET受け付けないから無理 842 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 01:09:04 ] f:viewは仕方ないにしても、h:formが必要ない書き方って標準でないんでしょうか？ 843 名前：デフォルトの名無しさん [2005/12/19(月) 07:45:39 ] ASP.NETのパクリ成功した？ 844 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 11:51:21 ] もう一息です 845 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 12:40:11 ] JavaEE5出てから本格始動だろうな 846 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 13:00:46 ] >facelets これ、素のHTMLのTableタグをdatatableとかpanlegridに置き換える方法が判んない。 847 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 19:32:55 ] >>840 じゃ、おまいには無理だ 848 名前：デフォルトの名無しさん [2005/12/20(火) 23:56:04 ] >>837 これでJSFにも勢いつくといいね。 ＞100を越えるJSFコンポーネントから構成されており 結構すごそう。 誰かもう触った人いる？ 849 名前：デフォルトの名無しさん mailto:sage [2005/12/24(土) 08:25:58 ] ちょっと試してみた。 tomahawkのように他のJSF実装と組み合わせて使う方式だから簡単に試せると 思ったが、子要素の解釈が結構違っていてかなりの書き換えが必要になりそう。 Sun RIだと子要素にHTMLタグを記述してもほぼそのまんま期待通りに動作 するけど、ADFはほとんど全滅。同等のJSFタグに置き換えるか、verbatimで 囲む必要があった。 一方でJSF標準はjstlとの併用がまったく考慮されていないのが不満だったけど、 ADFでは独自にforEachやswitcherなどを用意してくれているのがありがたい。 forEachはまだいろいろ制約があるみたいだけど。 850 名前：デフォルトの名無しさん mailto:sage [2005/12/24(土) 11:49:00 ] JSFも1.2はJSTLと併用できるみたいね。 851 名前：デフォルトの名無しさん mailto:sage [2005/12/24(土) 12:12:21 ] >>849 ＞Sun RIだと子要素にHTMLタグを記述してもほぼそのまんま期待通りに動作 するけど ものによる。 この問題を解決するために、JSF1.2/JSP2.1ではJSFタグに${...}を記述できるようになる。 ${...}は即時解釈（通常のJSPと同じタイミング）され、 #{...}はレスポンス描画フェーズで解釈される ・・・だそうだ。JavaOneでCraigとYUTAさんがそう言ってた。 852 名前：デフォルトの名無しさん mailto:sage [2005/12/26(月) 10:54:37 ] 求む人柱 www.alphaworks.ibm.com/tech/faces4laszlo 853 名前：デフォルトの名無しさん mailto:sage [2005/12/27(火) 01:40:08 ] 人柱って、、、試したところで何のデメリットもないんだから手前で試せよ。 854 名前：デフォルトの名無しさん mailto:sage [2005/12/27(火) 09:30:17 ] 環境が無いんだよ 855 名前：デフォルトの名無しさん mailto:sage [2005/12/28(水) 00:22:42 ] >>854 どういう意味だ？ 856 名前：デフォルトの名無しさん mailto:sage [2005/12/28(水) 01:00:43 ] 家にも会社にもPCが無いんだろ。 2ちゃんは携帯からか？ 857 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 11:04:18 ] >>856 すごいなｗ 858 名前：デフォルトの名無しさん mailto:sage [2006/01/03(火) 03:33:41 ] JSFって、実際のところどうですか？ 859 名前：デフォルトの名無しさん [2006/01/03(火) 22:34:23 ] 悪くないよ。 でも基本的にグラフィカルIDEが必要。 コードで書くもんじゃない。 860 名前：デフォルトの名無しさん mailto:sage [2006/01/03(火) 23:08:36 ] テキストベースのコードを直書きしても、Strutsよりはるかにマシ。 GUIベースのIDEは、下記の点を割りきればOK。 ・ベンダ依存のコードになる（他のツールでの編集は考えてはいけない） ・ソースを直接編集することは一切考えない（上に同じ） ・自動生成されたコードがキモい 861 名前：デフォルトの名無しさん [2006/01/04(水) 00:56:06 ] >>859 JSFを信じない人のために: JSFに関するFUDをクリアーする www-06.ibm.com/jp/developerworks/java/050527/j_j-jsf1.html これによると >JSFに関しては3つの大きな誤解がありますが、その第1は、作業のためにWYSIWYGツールが必要だというものです。 だってさ。 詳しくは読んでないから知らんが。 862 名前：デフォルトの名無しさん mailto:sage [2006/01/04(水) 01:20:14 ] >>861 >『WYSIWYGツールを使わなくても、JSF開発はStrutsよりもずっと簡単なのです！』 あくまでもStrutsに対する相対評価だね。 863 名前：デフォルトの名無しさん mailto:sage [2006/01/04(水) 03:16:51 ] Java初心者なんですが、できるだけお手軽にWebアプリを作りたいので、 JSFに注目してます。 Javaっていろんなフレームワークがあって、何から手をつけてよいのか迷い ます。 JSFでWebアプリを作れるようになるには、どういう順序で勉強すればいいの でしょうか。 Javaの基礎（文法）⇒JSPとサーブレット⇒JSF こんな感じでいいでしょうか。 864 名前：デフォルトの名無しさん mailto:sage [2006/01/04(水) 08:08:46 ] 順番はそれでいいと思うけど、単にお手軽につくりたいだけならPHPの方がいいような･･･ 865 名前：デフォルトの名無しさん mailto:sage [2006/01/04(水) 11:31:15 ] >>863 sun java studio creator を使え。 それでもだめならあきらめろ。 866 名前：デフォルトの名無しさん mailto:sage [2006/01/04(水) 16:49:33 ] 863です。レスありがとうございます。 >>864 PHPとASP.netは使えます。これらに慣れすぎたせいでJavaでもお手軽に 作れないかなという気持ちになってしまいました。 >>865 早速ゲットしました。これが無料って、すごいですね。 867 名前：デフォルトの名無しさん [2006/01/04(水) 19:36:08 ] sun java studio creatorを使いこなせれば、 たいていのWEBアプリはOKだと思う。 868 名前：デフォルトの名無しさん mailto:sage [2006/01/04(水) 19:42:52 ] >JSFに関しては3つの大きな誤解がありますが、その第1は、作業のためにWYSIWYGツールが必要だというものです。 必要なんじゃなくて、ツールと一緒に使うことも視野に入っているだけ 869 名前：デフォルトの名無しさん mailto:sage [2006/01/04(水) 20:04:06 ] はいどうぞ。 pcweb.mycom.co.jp/articles/2006/01/01/whatisjsf/ 870 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 00:07:12 ] JSFにはバリデーションマスクみたいな機能ってないんでつか？ わざわざActionListenerでコンポーネントツリーつかってシコシコ processValidators呼んでやんないとだめなんすか？ それともこんな質問してる俺が馬鹿なだけですか？ 871 名前：デフォルトの名無しさん [2006/01/17(火) 16:33:55 ] JSPから引数があるメソッド呼ぶ方法ってないの？ こんなのを呼びたい public String getLabel(int state) { return (state == 0 ? "０" : "１"); } エンティティに表示文字列を意識させたくない 872 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 16:41:54 ] 普通に呼び出せばいいと思うが。 しかし、選択肢はJSPかエンティティしかないのか？ 873 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 17:07:51 ] 具体的にどうすれば良いのだ？ #{hoge.label} の形式では無理なのか？ 874 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 17:50:40 ] スクリプトレット使えばよかろう。 875 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 18:22:50 ] <t:dataTable value="#{aaa.hogeList}" var="hoge"> 　<h:column> 　　<f:facet name="header"> 　　</f:facet> 　　<%= hoge.getLabel() %> 　</h:column> </t:dataTable> せんせーできません 876 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 19:04:37 ] page.getAttributeじゃねぇの？ 877 名前：デフォルトの名無しさん [2006/01/17(火) 19:48:54 ] そもそもdataTableタグの中でスクリプトレット使えないから・・ 878 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 19:50:38 ] >>877 JSF1.1まではね。 879 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 20:20:55 ] 俺らみたいな低民族がまともに開発できるバージョンで教えてくれ 880 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 01:39:20 ] JSFってどんなものか試しにSun Java Studio Creator使ってみたけど、 凝ったことやろうとするとなんか面倒じゃね？ 881 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 07:36:45 ] >>880 それはCreatorが面倒なだけ。 882 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 07:49:08 ] >>878 便乗だけど、JSF1.2で動かそうと思ったら、今はGlassFishしかないの？ そもそもTomcat6が作られてないからServlet2.5、JSP2.1も（GlassFish以外に）今は無い？ 883 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 11:28:49 ] >880 Eclipse＆JSP手書きで充分 884 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 12:26:05 ] 俺もポトペタ要らん派だけど、beanやproperty/methodの 存在チェックくらいして欲しいと思わないかい？ 885 名前：デフォルトの名無しさん [2006/01/18(水) 21:05:18 ] バッキングBeanって基本的に1つのサービスに対してしか必要ない？ 886 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 22:10:03 ] どういうこと？ 887 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 22:13:19 ] >>884 NetBeans5の、タグをポトペタする機能は便利だよ。 h:dataTableなんかをパレットからD&Dしてデータを指定したら、適当なh:columnなんかが入ってくれる。 新しいアイテムの自作も難しくないし。 JSFではWYSIWYGではない環境でのポトペタが便利だと思う。 888 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 22:18:46 ] なんか１画面で１つのバッキング・ビーンを定義するっていう風潮があるじゃんか 無駄なんだよな。 本当にバッキング・ビーンとして扱うべきものは、状態が変化するモノなんじゃないかと。 そうなると必然的にサービスと紐付いてくるわけさ 889 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 00:36:10 ] そうするメリットってどんなものがあるの？ 個人的にはどっちでもいいけど、画面項目設計書から余計な事を 考えなくとも、機械的にソース吐けるから大した手間でもないし、 Beanは画面から送られる使い捨てキャリアとしてしかみてない、 且つ、1画面=1Beanでシンプルでよいし・・ということで、気にせず 作ってしまってるんだけど。。 890 名前：デフォルトの名無しさん [2006/01/19(木) 01:24:07 ] ・メリット コード量が圧倒的に少なくて済む ・デメリット 画面開発者がどのBeanを使うかを理解しないといけない 逆に１つの画面で１つのBeanにすると ・メリット 画面中心で単純 ・デメリット 同じ処理を複数回書く必要がでてくる コードが増える うざい くさい 画面が増えたとき面倒 メモリ使用量が増える 設定ファイルの記述が増えるのも面倒 画面間の値の受け渡しに気を遣う必要がある とりあえず、 定型ソースと言えど、人間が触る部分のコード量が多いのはシステムの見透しが悪くなるからうざいのと、 同じことを何度も書くのはあほらしい 891 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 02:22:42 ] >・デメリット >画面開発者がどのBeanを使うかを理解しないといけない これはメリットのわりにはかなり痛いデメリット。 自分ならやっぱ1画面=1Beanを選択するよ。 （多数の初心者のような開発者抱え込む場合ならなおさら） 対して1画面=1Beanのデメリットはどれも小さいものばかり。 その中では実際デメリットにもなりえないものも、いくつかあると思う。 892 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 05:20:43 ] >>891 >画面開発者がどのBeanを使うかを理解しないといけない これは実際には、画面開発者がどの機能を実装しているかを理解しないといけないということ。 画面ごとにBeanを作ると、持ちまわるべきデータを分断してしまうことになって、そのためのロジックが必要になったりする。 大きな機能ごとの幹になるBeanを作って、細かい画面制御的なBeanが必要なときは画面ごとに用意するというような、ハイブリッドな考え方。 どちらかにこだわると失敗する。 893 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 09:52:29 ] >891 どこが小さいデメリットばかりなんだよ >画面開発者がどのBeanを使うかを理解しないといけない これは設計者がちゃんと指示すれば済む問題 894 名前：デフォルトの名無しさん [2006/01/19(木) 18:08:01 ] ちょっともどるが>>871みたいなのはコンバータ作るべきなんじゃね？ 895 名前：デフォルトの名無しさん [2006/01/19(木) 19:00:16 ] >894 目からうろこ ﾏｼﾞｻﾝｸﾇ！ 896 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 23:50:32 ] >同じ処理を複数回書く必要がでてくる >コードが増える >画面が増えたとき面倒 >設定ファイルの記述が増えるのも面倒 これらは工数として見たとき、どちらを採用しても大した違いはないと 思うんだけどな。 仮に差があったとしてもシステム全体で考えても数人日程度だと思う。 （どっちが工数大きくなるかは置いておいて） >メモリ使用量が増える これは逆じゃない？ごった煮Beanの方が状態管理する必要のないものまで セション管理される可能性が高いと思う。 それでも微々たるもので、メモリを圧迫するレベルとはかけ離れた レベルの話だと思うけど。 >画面間の値の受け渡しに気を遣う必要がある ごった煮の1Beanだとある状況で扱う項目/扱わない項目がでてくるわけだから、 1画面=1Beanで気を使う部分とは別に、意識しなければならない要素がでてくると思う。 （このタイミングでこの項目は使うんだっけ？？みたいな感じで何度も設計書を 見直さなければならないとか） 897 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 23:56:59 ] >それでも微々たるもので、メモリを圧迫するレベルとはかけ離れた >レベルの話だと思うけど。 自己レスだけど、これは仕様によるからなんともいえないね。 大きなデータ構造を何百件ももつ必要がある場合とかは考慮が必要だと思う。 そこまで大きなデータを持たなければならない状況もレアだと思うけど。 898 名前：デフォルトの名無しさん mailto:sage [2006/01/20(金) 01:53:35 ] >896 項目数もアクセス数も画面数も少ないのなら1画面1Beanの場合でもリソースやそれの管理に伴う時間なんかは無視できるかもな ただ聞きたいんだがManagedBeanってSessionからはいつ消えるの？ どこからごった煮という定義になったのか知らんが、ごった煮という定義は間違ってる。 おそらく1機能＝1Beanという理解をしているんだろうが、それも一つの手ではあるがあまり良い手ではない。 Managed-Bean（≒バッキング・ビーン）は、 1つのサービスを起動する際に関係のある 状態が変化するオブジェクト と位置づけてはどうだろうか？と。 >ごった煮の1Beanだとある状況で扱う項目/扱わない項目がでてくるわけだから、 サービスが必要とする最低限の項目のみで良いからそんなことにはならん >1画面=1Beanで気を使う部分とは別に、意識しなければならない要素がでてくると思う。 画面間でオブジェクトを受け渡す場合、「えーっと、、、次の画面のBeanはなんだっけ？？」みたいになるだろ。 画面遷移を意識するはnavigation-ruleだけでお腹いっぱい 899 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 02:23:11 ] 昨日からJSF始めたんだけど、Managed-Beanてのは、プレゼンテーション層用の Beanて認識でいいの？ 今まで自作フロントコントローラーからビジネスロジックのコマンド実行する 方法ばかりやってたせいかいまいちピンと来ない・・・ 900 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 10:05:55 ] >899 正解。 ビューコントローラに相当します。 901 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 01:28:32 ] >899 ハッキリ言ってどうにでも使える。 上の方でもやってるが、ビューとしてもOKだし、ビジネスロジックへの橋渡しとだけ考えても良い 重要なのはどうやるかをキチンと決めて、一貫性のある開発方法を作ること 902 名前：デフォルトの名無しさん [2006/01/25(水) 09:58:34 ] >>899 参考までにオレのやり方を露出 managed-bean(オレはp層と認識) 　　↓ facade(serviceLayer) 　　↓ facadeImple(ApplyTransactionPointByAOP) 　　↓ dao 　　↓ daoImple(dataStoreLayer) こんな感じでやってる。

---

---

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

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