web-dev-qa-db-ja.com

Seam、Wicket、JSF、GWTのどのフレームワークを選択する必要がありますか？

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

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

これらの中から決定する際に考慮すべき要素は何ですか？

javajsfseamwicketweb-frameworks
20
karl

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

長所：

  • フェイスレットxhtmlコンポーネントの作成は簡単で、再利用を促進します。
  • Ui：insert、ui：include、ui：decorateなどの組み込みタグを使用した適切なテンプレート機能
  • Faces-configを介したSpringBeanへの簡単なアクセス
  • XHTMLベースなので、Javaに慣れていないWeb開発者は引き続き効果的です
  • Tomahawk/trinidadで利用可能な優れたウィジェットライブラリ

短所：

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

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

JSF 2.0のアップデート：

  • 複合コンポーネントでさらに優れた再利用機能を備えています
  • 2.0のウィジェットライブラリには、primefacesとmojarrascalesが含まれています
  • リクエストの取得とブックマークを許可します
  • Ajaxサポートが組み込まれています
  • JSF 2の詳細については、 http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/ を参照してください。
18
digitaljoel

バージョン1.4以降はGWTを使用し、2.0仕様が発表されてからはJSFを使用しています。

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

  • 粗粒度のサービスを使用するのが最適
  • クライアント側に移動するすべてのオブジェクトは完全にシリアル化可能である必要があります（つまり、遅延読み込みやOpenSessionInViewパターンがないことを意味します）
  • GWT 2.0以降、xhtmlを使用してGUIを設計できます。これは、HTMLのスタイル設定と構造化に関してはるかに簡単です。
  • GWTは優れたアーキテクチャを好む傾向があります。それを台無しにすると、リファクタリングするのはbadになります。
  • Perfect履歴（ブラウザの戻るボタン、ブックマーク可能なURL）のサポートはハード、簡単ですが、おそらく自分でロールする必要があります何かを前もってハックする

JSFはコンポーネントベースのフレームワークであり、ビューファーストデザイン（必要に応じてコードビハインド）を備えています。

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

履歴書：

  • [〜＃〜] gwt [〜＃〜]は、クライアント側で最高のパフォーマンスを必要とするWeb アプリケーション（Gmailを考えてください）に適しています。カスタムコンポーネントを作成するのは簡単です（Javaを作成します）。サーバー側は単なるサービスレイヤーであるため、サーバー側で完全にステートレスにすることができます。
  • [〜＃〜] jsf [〜＃〜]は、コンポーネント指向のものに適したほとんどのCRUDアプリケーションに適しています。ホテル/フライト予約システム、ショッピングカートを備えたオンラインストアを考えてみてください。 、など
34
Miguel Ping

冷静さを保ち、この議論を続けてくれた改札の人たちに感謝します。私は改札ユーザーで、大好きです。私の主な理由は：

  1. そのコンポーネントフレームワーク。全ページではなく、コンポーネントを操作するのが大好きです。

  2. Javaパーツで作業するときに、デザイナーにテンプレートとページで作業させることができます

  3. 学ぶべき新しいことは何もありません。その「ちょうどJavaそしてちょうどHTML」

  4. 私はそのajaxフォールバックメカニズムが好きです。特にモバイルデバイスのブラウザでJavaScriptがサポートされていない場合は、プレーンhtmlにフォールバックし、すべてが機能します。
  5. Xml構成の欠如はプラスです
  6. それは私がウェブアプリケーションに望むすべてをサポートします。例：検証、国際化、戻るボタンのサポート、RESTfulURLなど

私の以前の経験はGWTとJSF1.0です

15
joshua

Seamはアプリケーションフレームワークであり、実際にはプレゼンテーション層ではありません。もともとはJSFの痛みを軽減するために開発されましたが、より汎用的な依存性注入フレームワークに進化しました。

SeamはJSF、Wicket、GWTで使用できると思います。 JSFサポートは主要で優れています。他の2つがどれだけうまくサポートされているかわかりません。

あなたの基準の焦点はあなたのスキルの市場性にあるように思われるので、Faceletsを介してSeamとJSFを試してみることをお勧めします。 JSFは広く受け入れられている標準であり、Faceletsを使用している場合は実際に使用するのが楽しいです。 RichfacesとAjax4jsfを介して滑らかなAJAX機能を使用できます。Seamは、JCPを介して多かれ少なかれ標準化されています。

10
recampbell

私の経験は、時系列で次のとおりです。

生のサーブレット-（ええ、大変な作業がたくさんありますが、それは初期の頃であり、私たちは熱心なビーバーでした！）

JSP-出てきたときはビーズニーズだと思っていました（知っていれば;））

Echo-素晴らしいフレームワークですが、検索エンジンに対応する必要のあるページには適していません（GWTと同じ問題）

Wicket-素晴らしいフレームワーク-開発者はOO（JSPや他の多くのものとは異なり）の概念を完全に理解し、このフレームワークに通常のすべてのOO）を適用しました。 「再利用可能性」、カプセル化、関心の分離、オブジェクトマーシャリングやその他の醜さを気にせずにモデルをUIコードにバインドしたい場合は、これがフレームワークです。

7
Volksman

長期的なシナリオでは、Sunの仕様に裏打ちされたテクノロジーを使用することをお勧めします。これはこれまでのところ、複数の実装を提供して選択をもたらすことが証明されており（多くの場合、オープンソースの実装も）、さらに動作は非常に明確に定義される傾向があります。

これは、メンテナンスシナリオで役立ちます。これにより、コードが時間内に終了することを願っています。よく書かれたコードは永遠に生きます:)

この特定のシナリオでは、JSFを提案します。私は1.1のApache実装を試しただけですが、JSPの上にあるのは痛いです。間もなく改訂する予定です。フェイスレットにJSFを搭載することを検討する予定です。

3
Thorbjørn Ravn Andersen

求人市場のみを検討する場合は、JSFを選択する必要があります。しかし、RIAの将来は、クライアントサイドテクノロジーのようなGWTとgwtに属すると私は信じています。

GWTの最も明らかな利点は、JSFやウィケットなどのサーバー側のプレゼンテーション層テクノロジーよりもスケーラブルであると思います。 、サーバーはクライアントの状態を保存する必要がなく、クライアントのCPUパワーも使用されるためです。これは大きな利点であり、フォールトトレラントシステムを実現するためにサーバーコンピューター間でクライアントの状態をシリアル化する必要はありません。

1
Gursel Koca

私はJSF（1.1と1.2）から始めましたが、とても苦痛だったので、次のプロジェクトで変更することにしました。少し調べて、Wicketを試してみることにしました。とても楽しかったです。また、JSF 2を試しましたが、それでも同じです。

どちらもコンポーネントフレームワークですが、Wicketを使用することは簡単ですが、JSFを使用することは完全に混乱しています。

JSFの改札：

  • WicketではHTMLはHTMLです。 JSFには独自のマークアップタグがあります。 h：dataTable（テーブル用）は意味がありません。私を信じてください、それを設計したとき、SunEngineersは酔わなければなりませんでした。
  • Wicketのセキュリティなどでは、
  • JSFを使用すると、ナビゲーションバーに前のURLが表示されます。本当に奇妙です。
  • JSFは私には非常に重いように思えますが、RichやPrimeのようなライブラリはさらに多くあります。
  • 時々、どちらが起こっているのかを知ることが不可能に思えます。 JSFがなぜやっているのかわからないので、あなたはいつもあなたのコンピュータに怒鳴ります。

JSF over Wicket：

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

一般的な欠陥の1つは、セッションサイズに問題があることです（グラフィカルコンポーネントがそこに格納されているため）。

全体として、WicketとJSFのどちらかだけを決定する必要がある場合は、疑いの余地はありません。Wicket。

1
polypiel

私はWicketとGWTをかなり頻繁に使用しました。 Wicketを愛することを本当に学んだことはありません。

私のエゴはそれについてブログに書いています http://salk31.blogspot.com/2009/07/wicket-ajax.html

今日GWT2.0 uiBinderを見ると、XMLコンポーネントツリーをJavaで作成されたものと一致させる必要があるのがWicketでどれほど面倒であるかを思い出しました。これに関するGWTスピンは、私には非常に良く見えます。

私は1年以上Wicketを使用していないので、おそらくこれを多く修正しましたが、最新のブラウザーとJSのサポートを考えると、サーバー上でこれらすべてを実行する意味がわかりません（データの局所性を知っています）。

1
salk31

私はそれが少し遅いことを知っていますが、Framewrok、特にこれはすでに多くの比較があり、Devox 2010 confで発生しました：

http://www.devoxx.com/display/Devoxx2K10/Comparing+JVM+Web+Frameworks

これはあなたが選ぶのを助けるはずです:)

1
Jean-Rémy Revy