昨日、Java Server Faces 2.0 のプレゼンテーションを見ましたが、私は現在 ASP.NET MVC / jQuery 開発者として満足していますが、本当に感銘を受けました。JSF で一番気に入ったのは、AJAX 対応の UI コンポーネントが大量にあり、特に AJAX を多用するサイトでは、ASP.NET MVC よりも開発がはるかに速くなるようです。統合テストも非常に良さそうです。
プレゼンテーションでは JSF の利点のみが強調されていたので、他の側面についてもお聞きしたいです。
私の質問は次のとおりです:
- Java Server Faces 2.0 の主な欠点は何ですか?
- JSF 開発者が JSF の代わりに ASP.NET MVC の使用を検討する理由は何でしょうか?
ベストアンサー1
JSF 2.0 の欠点は何でしょうか? 正直なところ、基本的な Web 開発(HTML/CSS/JS、サーバー側とクライアント側など) と基本的な Java サーブレット API (リクエスト/レスポンス/セッション、転送/リダイレクトなど) に関する確かな背景知識がない場合の比較的急な学習曲線を除けば、深刻な欠点は思い浮かびません。現在のリリースの JSF は、初期の頃にいくつかの深刻な欠点があったときに得た否定的なイメージをまだ取り除く必要があります。
JSF 1.0 (2004 年 3 月)
これは最初のリリースでした。コア領域とパフォーマンス領域の両方に、知りたくないバグが満載でした。Web アプリケーションは、直感的に期待したとおりに動作しないこともありました。開発者は泣きながら逃げ出すことになるでしょう。
JSF 1.1 (2004 年 5 月)
これはバグ修正リリースでした。パフォーマンスは、まだあまり改善されていませんでした。また、大きな欠点が 1 つありました。JSF ページに HTML を完璧にインライン化できないことです。プレーンな HTML はすべて、 JSF コンポーネント ツリーの前にレンダリングされます。プレーンな HTML はすべてタグで囲んで、JSF コンポーネント ツリーに含まれるようにする必要があります<f:verbatim>。これは仕様どおりでしたが、多くの批判を受けています。ao JSF/Facelets も参照してください。JSF/Facelets と HTML タグを混在させることはなぜ好ましくないのでしょうか?
JSF 1.2 (2006 年 5 月)
これは、Ryan Lubke が率いる新しい JSF 開発チームの最初のリリースでした。新しいチームは多くの素晴らしい仕事をしました。仕様にも変更がありました。主な変更点は、ビュー処理の改善です。これにより、JSF が JSP から完全に切り離され、JSP とは異なるビュー テクノロジを使用できるようになっただけでなく、開発者はタグに煩わされることなく、JSF ページにプレーンな vanilla HTML をインライン化できるようになりました。新しいチームのもう 1 つの主な焦点は、パフォーマンスの改善でした。Sun JSF Reference Implementation 1.2 (2008 年頃のビルド 1.2_08 以降、コード名はMojarra<f:verbatim> )の存続期間中、実質的にすべてのビルドで、通常の (マイナーな) バグ修正に加えて (メジャーな) パフォーマンスの改善が行われました。
JSF 1.x (1.2 を含む) の唯一の重大な欠点は、リクエスト スコープとセッションスコープの間に、いわゆる会話スコープがないことです。これにより、開発者は、より複雑な Web アプリケーションで検証、変換、モデル変更、アクション呼び出しを正常に処理するために、後続のリクエストで初期モデル データを保持したい場合、非表示の入力要素、不要な DB クエリ、および/またはセッション スコープの乱用で苦労する必要がありました。この苦労は、MyFaces Tomahawk <t:saveState>コンポーネント、JBoss Seam会話スコープ、MyFaces Orchestra会話フレームワークなど、後続のリクエストで必要なデータを保持するサード パーティ ライブラリを採用することで軽減できます。
HTML/CSS 純粋主義者にとってのもう 1 つの欠点は、JSF がコロンを:ID 区切り文字として使用しidて、生成された HTML 出力内の HTML 要素の一意性を保証することです。これは、特にコンポーネントがビュー内で複数回再利用される場合 (テンプレート化、コンポーネントの反復処理など) に当てはまります。これは CSS 識別子では不正な文字であるため、CSS セレクターでコロンをエスケープするには を使用する必要があります。その結果、や のよう\な見苦しく奇妙なセレクターが生成されます。「CSS セレクターでコロン ":" を使用して JSF が生成した HTML 要素 ID を使用する方法」も参照してください。ただし、純粋主義者でない場合は、「デフォルトでは、JSF は使用できない ID を生成します。これは、Web 標準の CSS 部分と互換性がありません」も読んでください。#formId\:fieldId {}#formId\3A fieldId {}
また、JSF 1.x には Ajax 機能が標準で付属していませんでした。これは技術的な欠点ではありませんが、当時の Web 2.0 の流行により機能上の欠点となりました。Exadel はAjax4jsfを早くから導入し、これは長年にわたり徹底的に開発され、JBoss RichFacesコンポーネント ライブラリのコア部分となりました。他のコンポーネント ライブラリにも組み込みの Ajax 機能が付属しており、よく知られているのがICEfacesです。
JSF 1.2 のライフタイムの半ば頃に、新しい XML ベースのビュー テクノロジであるFaceletsが導入されました。これは、特にテンプレートの領域で JSP を上回る大きな利点を提供しました。
JSF 2.0 (2009 年 6 月)
これは、Ajax が流行語となった 2 回目のメジャー リリースでした。多くの技術的および機能的な変更がありました。デフォルトのビュー テクノロジとして JSP が Facelets に置き換えられ、Facelets は純粋な XML を使用してカスタム コンポーネント (いわゆる複合コンポーネント) を作成する機能で拡張されました。JSF2.0以降のビュー定義言語として、なぜ Facelets が JSP よりも好まれるのかについても参照してください。
Ajax の機能は、Ajax4jsf と多くの類似点を持つコンポーネントのフレーバーに導入されました。冗長なファイルをできるだけ削減する<f:ajax>ために、注釈と設定より規約の強化が導入されました。また、デフォルトの命名コンテナー ID 区切り文字が構成可能になったため、HTML/CSS 純粋主義者も安心できます。必要なのは、名前でとして定義し、 など、クライアント ID のどこにもその文字を使用していないことを確認することだけです。faces-config.xml:init-paramweb.xmljavax.faces.SEPARATOR_CHAR-
最後になりましたが、新しいスコープであるビュースコープが導入されました。これにより、前述の JSF 1.x のもう 1 つの大きな欠点が解消されました。@ViewScoped会話スコープを有効にするには、後続の (会話型) リクエストでデータを保持するためのあらゆる方法に煩わされることなく、Bean を宣言するだけです。Bean は、@ViewScoped同期的または非同期的 (Ajax) に、同じビュー (開いているブラウザー タブ/ウィンドウとは無関係) に送信してナビゲートしている限り存続します。マネージド Bean のビュー スコープとリクエスト スコープの違いと、適切な Bean スコープを選択する方法も参照してください。
JSF 1.x の欠点は実質的にすべて解消されましたが、致命的となる可能性のある JSF 2.0 固有のバグがあります。 は、部分的な状態保存における鶏が先か卵が先かの問題により、@ViewScopedタグ ハンドラーで失敗します。 これは JSF 2.2 で修正され、Mojarra 2.1.18 にバックポートされています。 また、 HTML5 などのカスタム属性の受け渡しはdata-xxxサポートされていません。 これは、JSF 2.2 で新しいパススルー要素/属性機能によって修正されています。 さらに、JSF 実装 Mojarra には独自の問題があります。 比較的多くの問題は、の直感的でない動作<ui:repeat>、新しい部分的な状態保存の実装、および実装が不十分なフラッシュ スコープに関連しています。 それらのほとんどは、Mojarra 2.2.x バージョンで修正されています。
JSF 2.0 の頃に、 jQuery と jQuery UI をベースにしたPrimeFacesが導入されました。これは最も人気のある JSF コンポーネント ライブラリになりました。
JSF 2.2 (2013 年 5 月)
JSF 2.2 の導入により、HTML5 は、技術的にはすべての古い JSF バージョンでサポートされているにもかかわらず、流行語として使われました。JavaServer Faces 2.2 と HTML5 のサポート、なぜ XHTML がまだ使用されているのか も参照してください。最も重要な新しい JSF 2.2 機能は、カスタム コンポーネント属性のサポートであり、これにより、カスタム テーブルレス ラジオ ボタン グループなど、可能性の世界が開かれます。
実装固有のバグや、バリデータ/コンバーターに EJB を挿入できないなどの「煩わしい小さな問題」(JSF 2.3 で既に修正済み) を除けば、JSF 2.2 仕様には実際には大きな欠点はありません。
コンポーネントベースの MVC とリクエストベースの MVC
JSF の主な欠点は、生成された HTML/CSS/JS をきめ細かく制御することがほとんどできないことだと考える人もいるかもしれません。これは JSF 自体の問題ではなく、JSF がコンポーネント ベースのMVC フレームワークであり、リクエスト (アクション) ベースのMVC フレームワークではないためです。MVC フレームワークを検討する際に、HTML/CSS/JS を高度に制御することが主な要件である場合は、コンポーネント ベースの MVC フレームワークではなく、Spring MVCなどのリクエスト ベースの MVC フレームワークを検討する必要があります。HTML/CSS/JS の定型文をすべて自分で記述する必要があることだけを考慮する必要があります。リクエスト MVC とコンポーネント MVC の違いも参照してください。
参照:
- JSF、サーブレット、JSP の違いは何ですか? (基本を理解するためだけに)
- JSF を使用してテーブルレス CSS レイアウトを開発する(JSF に関するもう 1 つの誤解)
- JSF とプレーン HTML/CSS/JS/jQuery (JSF が間違った選択である場合)
- Web アプリケーションのデザイン パターン(MVC の背後にある思想を説明します)