質問: 共有サーバー側の状態によるjsfの問題 最新のテクノロジーレーダーでは、thoughtworks jsfを回避することをお勧めします httpを介してステートフルネスを作成しようとすると、「共有サーバー側の状態に関連する多くの問題が発生する」ことになります。私はjsf2.xを2年近く使用していますが、気に入っています。そのような問題が発生したとは言えません。しかし、私はそれについてあまり経験がなく、代替案についてもそれほど経験がないので、それらの「問題のホスト全体」とは何かを理解したいと思います。jsfに関する質問は通常、白熱した議論を引き起こすので、明確にすることは有益だと思います。これはjsf 2.xに関するものですが、状態をhttpに入れることがアーキテクチャ的に正しいかどうかにかかわらず、xまたはyよりも優れているか悪いかについてではありません。そのようなもの。レーダーが詳細に進まないので、私はそれらの問題が何であるかを知りたいだけです。
回答: ステートフルhttpモデルの問題に関するいくつかの有用な事実を見つけることができました。元の「共有サーバー側の状態に関連する問題のホスト全体」はまだ曖昧に聞こえますが、私が収集した参照のいくつかは、ある程度(および解釈)それをカバーしています。まず、最も一般的な苦情の1つであるパフォーマンスの問題が発生します。 jsfは、クライアントとサーバーの間でビューステートを作成、管理、および送受信する必要があり、それは非常にコストがかかります。このコストは、次の方法である程度最小限に抑えることができます。 別の実装を使用する。私は2012年を見つけました ブログ投稿 それは2.1.7myfacesがmojarraの対応物よりもリソースをあまり消費しないことを指摘しています。常にパフォーマンスの問題があるため、これは将来のバージョンで変更される可能性があることに注意してください。 状態の保存を無効にします。これにより、これらすべての問題が実際に修正されますが、パフォーマンスはまだ最適ではありません。 この回答 は、無効状態のjsf2.2がプレーンサーブレットよりもまだ遅いことを示しています。それが有効な比較であるかどうかをユーザーが質問していることに注意してください。 第二に、州がクライアントに属していない場合、riaエクスペリエンスの提供はより困難になる可能性があります。これもパフォーマンスに帰着しますが、それ以上のようです。ステートフルhttpアプリケーションでデスクトップのようなエクスペリエンスをシミュレートするために、開発者はビューステートの複雑さに直接対処することになります。ある種のuiフローを実装することは、それを確認するための良い方法だと思います。それは動作しますが、かなり厄介です。 jsf 2.2は、開発者の仕事を容易にするためのフロースコープを提供しますが、それでも端が少し荒いことがわかりました。 この投稿 この種の問題の簡単な例を示します。最後に、ビューステートを保持するためにセッションに依存すると、インスタンス間でそのセッションを共有する必要があるため、アプリケーションのクラスタリング作業が困難になります。アプリケーションサーバーはそれを行うためのメカニズムを提供しますが、最終的にはより多くのリソースを使用することになります。また、一部のpaasプロバイダーはセッションレプリケーションの料金を請求します。 jsfのためにそれを使用することは、良い考えとは言えません。