Seam、Wicket、JSF、または GWT のどのフレームワークを選択すればよいですか?[閉まっている]

https://stackoverflow.com/questions/745029

09-09-2019
|

質問

Java プロジェクトのプレゼンテーション層の基盤として Seam、Wicket、JSF、または GWT のどれを使用するかについて議論しています。

私は、雇用市場の考慮事項、テクノロジーの新しさ、他の S.O. からの推奨事項に基づいて、Java Web フレームワークの選択をこのサブセットに絞り込みました。ユーザー。

これらの中から決定する際にはどのような要素を考慮する必要がありますか?

解決

私が使用したのは JSF だけなので、他のものについてフィードバックすることはできませんが、JSF についての私の見解は次のとおりです。私の経験では、JSP の JSF から facelet の JSF に変換した瞬間に作業がはるかに楽になったので、ここでは facelet に焦点を当てます。また、Seam と JSF は相互排他的ではないようです。

長所:

facelets xhtml コンポーネントの作成は簡単なので、再利用が促進されます。
ui:insert、ui:include、ui:decorate などの組み込みタグを使用した適切なテンプレート機能
faces-config を介して Spring Bean に簡単にアクセス
XHTML ベースなので Java に慣れていない Web 開発者でも効果的です
トマホーク/トリニダードで利用できる優れたウィジェットライブラリ

短所:

投稿リクエストのみ。これにより、ブックマークが困難になる可能性があります。
GWT ほど組み込みの ajax-y ではありませんが、Seam で使用すると修正される可能性があります

私は決して JSF/Facelets の専門家ではないので、見逃しているものが他にもあると思います。うまくいけば、他の誰かも詳しく説明してくれるでしょう。

JSF 2.0 の更新:

複合コンポーネントによりさらに優れた再利用機能を備えています
2.0 のウィジェットライブラリにはプライムフェイスとモジャラスケールが含まれています
取得リクエストとブックマークを許可します
Ajaxサポートが組み込まれています
見る http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/ JSF 2 の詳細については、

他のヒント

私はバージョン 1.4 から GWT を使用し、2.0 仕様の登場以来 JSF を使用してきました。

GWT はクライアント側のフレームワークであり、Java から JavaScript を生成します。あなたのアーキテクチャは純粋なクライアントサーバーになります。これは次のことを意味します。

粒度の粗いサービスを使用するのが最適です
クライアント側に送られるすべてのオブジェクトは完全にシリアル化可能である必要があります (遅延読み込みや OpenSessionInView パターンがないことを意味します)。
GWT 2.0 以降、xhtml を使用して GUI をデザインできるようになり、HTML のスタイル設定と構造化がはるかに簡単になりました。
GWT は優れたアーキテクチャを好む傾向がありますが、それを間違えると、悪いリファクタリングする
完璧履歴 (ブラウザの戻るボタン、ブックマーク可能な URL) のサポートは次のとおりです。 難しい, 、おそらく自分でロールする必要がありますが、直前に何かをハッキングするのは簡単です

JSF は、ビューファースト設計 (必要に応じてコードビハインド) を備えたコンポーネントベースのフレームワークです。

ある種の Web アプリ (ショッピングカートなどのステートフル) を実行する方が簡単です。
JSF+Seam は会話をサポートしています (複数のページにわたって状態を維持するウィザードのようなページを考えてください)。
あなた できる スタックに応じて OpenSessionInView を実装します。サービス/ビジネス層に EJB を使用する場合はおそらく推奨されません
JSF2には 素晴らしいです AJAX のサポート、RichFaces のようなコンポーネントスイートを使用すると、優れた Web アプリを構築できます
- ただし、JavaScript の優れた動作が必要な場合は、JavaScript を記述する必要があります。
JSF は、クライアント側またはサーバー側で現在の UI 状態を追跡します。これは、ネットワークトラフィックとサーバーメモリの間のトレードオフです。

再開する：

GWT ウェブにはより適切です アプリケーション (Gmail を考えてください) クライアント側で最高のパフォーマンスが必要です。カスタムコンポーネントを作成するのは簡単です (Java を作成します)。また、サーバー側は単なるサービス層であるため、サーバー側で完全にステートレスにすることができます。
JSF コンポーネント指向のものに適した主に CRUD アプリケーションに適しています。ホテルや航空券の予約システム、ショッピングカートを備えたオンラインストアなどを考えてください。

ウィケットの皆さん、冷静さを保ち、この議論を続けてくれてありがとう。私は Wicket ユーザーであり、とても気に入っています。私の主な理由は次のとおりです。

それはコンポーネントフレームワークです。私はページ全体ではなく、コンポーネントを使って作業するのが好きです。
私が Java パーツで作業しているのと同じように、デザイナーにテンプレートとページで作業してもらうことができます
新しく学ぶことは何もありません。それは「単なる Java と単なる HTML」です。
私はその ajax フォールバックメカニズムが気に入っています。ブラウザ、特にモバイルデバイスで JavaScript がサポートされていない場合は、プレーン HTML にフォールバックしてすべてが機能します。
XML 構成がないことは利点です
Web アプリケーションに必要なものはすべてサポートされています。例: 検証、国際化、戻るボタンのサポート、Restful URL など

私の以前の経験は GWT と JSF 1.0 です

Seamはアプリケーションフレームワークではなく、実際にプレゼンテーション層です。それは、もともとJSFは苦痛が少ないにするために開発されたが、より汎用的な依存性注入フレームワークへと進化してきました。

私はあなたがJSF、自動改札やGWTでSeamを使用することができると信じています。 JSFのサポートは、プライマリおよび優秀です。私は他の2つがサポートされてどれだけわからない。

あなたの基準の焦点は、あなたのスキルの市場のように見えるので、私はFaceletsの経由SeamとJSFを試してみることをお勧め。 JSFはよく受け入れられた標準であり、実際にはFaceletsのを使用している場合に使用する楽しいです。あなたはRichFacesのとAJAX4JSFを経由して滑らかなAJAX機能を持つことができます。 Seamは、多かれ少なかれJCPを通じて標準化されています。

私の経験では、年代順に、次のとおりです。

生サーブレット - （！ええ、たくさんのハードワークのそれは初期の頃だったと私たちは熱心ビーバーた）

JSP - 私はそれが出てきた時にbeezのneezだと思った（我々は唯一知っていた場合;））

エコー - 恐ろしいフレームワークではなく、検索エンジンフレンドリーである必要はページの（同じ GWTでの問題）

ウィケット - 恐ろしいフレームワーク - 開発者は、完全に（JSPおよび他の多くとは異なり）OOの概念を理解し、このフレームワークにすべての通常のOOの細かな点を適用しています。あなたは懸念の分離を認める場合は、カプセル化を感謝し、あなたがオブジェクトのマーシャリングおよび他のそのような醜さを気にすることなく、UIコードへのモデルをバインドしたい場合、これはあなたのためのフレームワークである場合は、「再利用性」を認める場合は<！ / P>

長期的なシナリオでは、私は、Sunの仕様に裏打ちされた技術を使用してお勧めします。これは、これまでの選択（頻繁にもオープンソース実装）が得られ、複数の実装を与えることを証明している、プラスの行動は非常に明確に定義される傾向がある。

うまくいけば - - あなたのコードが時間内にあまりにもなってしまいます。

これはメンテナンスのシナリオ、のお手伝いをします。よく書かれたコードは永遠に住んでいる：）

この特定のシナリオでは、私はJSFをお勧めします。私は1.1のApacheの実装を試してみましたが、それはJSPの上にあることを傷つけます。我々はすぐにそれを修正するためにある - 私はFaceletsの上でJSFを持つに見えることを期待します。

。

私はかなり重くウィケットとGWTを使用しました。実際に改札を愛することを学んだことはありません。

私の自我はそれについてブログ http://salk31.blogspot.com/ 2009/07 /改札-ajax.htmlする

今日GWT 2.0 UiBinderサンプルメッセージを見てみると、それはJavaで作成されたものとXMLコンポーネントツリーと一致する必要がウィケットにあったか迷惑なことを思い出しました。この上のGWTスピンは私には非常に良く見えます。

私は一年以上のためのWicketを使用していませんでしたので、多分、私はデータを知っている（私が知っている、彼らはこのたくさんのを修正したが、近代的なブラウザとJSのサポート与えられた私は、サーバー上のすべてのこれを行うためのポイントを見ることができません地域）ます。

あなたが唯一の雇用市場を考慮した場合、

は、JSFを選択する必要があります。しかし、私はRIAの未来は、クライアント側の技術のようにGWTとGWTに属していることを信じて。

私はGWTの最も明白な上振れは、そのようなJSF、改札などのサーバサイドプレゼンテーション層技術よりも優れてスケーラブルであると思います。、サーバはクライアントの状態もまた、使用されているクライアントのCPUパワーを保存する必要はありませんので...それはあなたがフォールトトレラントシステムをachiveするために、サーバーコンピュータ間でクライアントの状態をシリアル化する必要がいけない、大きな利点です。

私はそれが少し遅れて知っているけどFramewrok上の比較の多くは、すでに存在し、espciallyこの1、ウィッヒはDevox 2010 CONF durinf発生します：

http://www.devoxx.com/display/Devoxx2K10/比較+ JVM +ウェブ+フレームワークの

この選択するお手伝いをする必要があります）。

私は JSF (1.1 および 1.2) から始めましたが、あまりにも苦痛だったので、次のプロジェクトでは変更することにしました。少し調べた結果、Wicket を試してみることにしました。とても楽しかったです。また、JSF 2 も試してみましたが、やはり同じでした。

どちらもコンポーネントフレームワークですが、Wicket の場合は簡単ですが、JSF の場合は完全に混乱します。

JSF 上のウィケット:

Wicket の HTML は HTML です。JSF には独自のマークアップタグがあります。h:dataTable (テーブル用) はナンセンスです。信じてください、サンのエンジニアは酔って設計したのです。
Wicket ではセキュリティなど、
JSF では、ナビゲーションバーに前の URL が表示されます。本当に奇妙だ。
JSF は私には非常に重いように思えますが、Rich や Prime などのライブラリを使用するとさらに重くなります。
場合によっては、どちらが起こっているのかを知ることが不可能に見えることがあります。JSF がなぜ動作しているのか分からないため、いつもコンピューターに向かって怒鳴ることになります。

Wicket を介した JSF:

Wicket では、さらに Java (HTML とのバインディング) を記述します。少なくとも、IDE はリファクタリングと検証のサポートを提供します。
Wicket でのリソース管理は少し注意が必要です。
JSF にはさらに多くのドキュメントとサポートがあります

よくある欠点の 1 つは、セッションサイズに問題があることです (グラフィカルコンポーネントがそこに保存されているため)。

全体として、Wicket と JSF のどちらかだけを選択する必要がある場合、私にとっては疑いの余地はありません。 ウィケット.

JSFは非推奨になりました (2010 年にエバンジェリストが Web フレームワークを比較したり、Web フレームワークについて話したりするときに、JSF は比較対象のフレームワークとしてリストされていません)。

現在、本格的な大規模アプリケーションは GWT、YUI、JQuery などを使用して作成されています。

Google でいくつかの記事を読んでみてください。それは明らかです。

(JSF 上のすべてのジョブはレガシーアプリケーションをサポートします)。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow