20

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

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

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

4

11 に答える 11

34

バージョン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は、最高のクライアント側のパフォーマンスを必要とするWebアプリケーション（Gmailを考えてください）に適しています。カスタムコンポーネントを作成するのは簡単です（Javaを作成します）。サーバー側は単なるサービスレイヤーであるため、サーバー側で完全にステートレスにすることができます。
  • JSFは、コンポーネント指向のものに適したほとんどのCRUDアプリケーションに適しています。ホテル/フライト予約システム、ショッピングカート付きのオンラインストアなどを考えてみてください。
于 2010-08-31T16:02:57.600 に答える
18

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

長所：

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

短所：

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

私は決して JSF/Facelets の専門家ではありません。うまくいけば、他の誰かも詳しく説明します。

JSF 2.0 の更新:

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

しらふで、この議論を続けてくれたウィケットの連中に感謝します。私は改札のユーザーで、それが大好きです。私の主な理由は次のとおりです。

  1. コンポーネントフレームワークです。フルページではなく、コンポーネントを扱うのが好きです。

  2. 私が Java 部分で作業するように、デザイナーにテンプレートとページでの作業を任せることができます。

  3. 新しく学ぶことは何もありません。その「JavaとHTMLだけ」

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

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

于 2010-08-10T05:13:02.930 に答える
10

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

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

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

于 2009-04-13T20:59:00.033 に答える
7

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

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

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

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

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

于 2011-02-10T22:37:10.210 に答える
3

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

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

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

于 2009-04-17T01:13:08.773 に答える
1

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

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

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

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

于 2009-10-28T16:42:06.843 に答える
1

求人市場のみを検討する場合は、JSF を選択する必要があります。しかし、RIA の未来は GWT と gwt のようなクライアント側の技術に属すると私は信じています。

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

于 2010-05-21T13:14:08.590 に答える
1

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

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

これはあなたが選択するのに役立つはずです:)

于 2012-09-13T14:40:05.590 に答える
1

私は 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 のどちらかのみを決定する必要がある場合は、Wicketに疑いの余地はありません。

于 2012-09-13T17:47:13.300 に答える
-10

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

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

グーグルでいくつかの記事を読んでください。上記は明らかです。

(JSF 上のすべてのジョブは、レガシー アプリケーションをサポートするためのものです)。

于 2010-05-04T20:54:06.637 に答える