私は常にステートレス Web を支持してきましたが、ステートフル Web の支持者が何を言っているのか知りたいです。
ステートレスよりもステートフルの方が適している状況はありますか?
13864 次
5 に答える
8
私たちのプロジェクトは、ステートフルまたはステートレスなやり取りを可能にする Wicket Web フレームワークを使用しています。ステートフル ページには多くの利点があります。
- wicket でステートフル ページを使用すると、wicket の AJAX フレームワークを使用して部分的なページ更新を実行しやすくなります
- ステートフルは、より「直感的な」プログラミング モデルです。たとえば、ウィケット ページ クラスでは、サーバー側でプライベート メンバー フィールドを宣言し、ページが読み込まれるときに設定し、AJAX リクエストがページにヒットして更新を実行するたびに再度アクセスすることができます。
- Wicket は、要求を処理するときにユーザー セッション オブジェクトを同期することにより、Web 層で最も一般的な同時実行の問題を防ぎます。
- サーバー側に状態を保存すると、パフォーマンスが向上する場合があります。たとえば、作成に時間がかかるがページで使用できる必要があるオブジェクトは、ページが最初にインスタンス化されたときに 1 回しかロードできません。
ステートフル アプリケーションで可能なことはすべて、ステートレスとして実装することもできます。クライアントに状態を保存し、すべてのリクエストで関連するすべての状態情報を送信するだけです。
ウィケットへのリンク: http://wicket.apache.org/
于 2009-09-23T02:11:01.190 に答える
4
通常、状態を使用すると、プログラマーの作業が容易になります。
ただし、状態は、ステートレスな状況では存在しない、あらゆる種類の同時実行の問題も引き起こします。
これは基本的に、関数型プログラミングと命令型プログラミングの間の議論です。
于 2009-07-24T12:49:55.683 に答える
2
私はスケーラブル性のためにステートフルクライアント-ステートレスサーバーキャンプにいますが、ステートレスサーバーを使用してこれを実装するのが難しくなった理由を説明するハードルに直面すると、長期的には一種の辞任になります。これはステートフルサーバーが輝く場所です:)。私はstatefullクライアントを好みますが、これはasp.net viewstateを使用して効率的に実装するのは簡単ではなく、おそらくこれがstatefullWebが実用的になる場所です。ステートフルクライアント、ステートレスサーバーを使用すると、タイヤ間でやり取りされるデータの量をより正確に把握できるようになると思います。これは、ステートフルサーバープログラミングモデルを使用して問題が発生するまで隠されることがあります。また、ステートレスからステートフルに移行するのは簡単です（すでに知っているので、提供している状態情報は無視してください。。）。反対に行くことはほとんど不可能です/それだけの価値はありません。ステートフルサーバーを使用するもう1つの点は、ステートフルクライアントも使用している場合、ステート/キャッシュのクリアが問題になることが多いことです。それは直感的で混乱しているだけです、またはマビーは私だけです:)
とにかく、GWTや他の多くの最新のツールキット（SilverlightがWCFと通信）は、拡張性の問題から、ステートフルクライアント、ステートレスサーバーを好むようです。ステートフルサーバーはステートレスルールの例外かもしれません...ページ/ウィンドウごとに選択できます。
于 2009-10-06T16:51:51.767 に答える
2
トラフィックが増え始めると、ステートレス Web アプリケーションが不可欠になります。
たとえば、セキュリティ上の理由から、クライアント側に保存したくないユーザーデータがたくさんある可能性があります。この場合、サーバー側に保存する必要があります。Web アプリケーションのデフォルト セッションを使用することもできますが、アプリケーションのインスタンスが複数ある場合は、各ユーザーが常に同じインスタンスに送られるようにする必要があります。
多くの場合、ロード バランサーには「スティッキー セッション」を持つ機能があり、ロード バランサーはユーザー リクエストを送信するサーバーを何らかの方法で認識します。ただし、これは理想的ではありません。たとえば、Web アプリケーションを再起動するたびに、接続されているすべてのユーザーがセッションを失うことを意味します。
より良いアプローチは、セッションを Web サーバーの背後にある何らかのデータ ストアに保存することです。最近では、これに使用できる優れた nosql 製品がたくさんあります (redis、mongo、elasticsearch、memcached)。このように、Web サーバーはステートレスですが、サーバー側にはまだ状態があり、適切なデータストア設定を選択することでこの状態の可用性を管理できます。これらのデータ ストアは通常、優れた冗長性を備えているため、ほとんどの場合、ユーザーに影響を与えることなく Web アプリケーションやデータ ストアに変更を加えることができます。
于 2013-08-22T12:24:13.810 に答える
1
ユーザーがどのページ/ステージにいるかを簡単かつ単純な方法で実際に追跡できるため、長いフォーム (および実際には複数のページの更新が必要なもの) のようなものは、永続的な状態を使用するとはるかに簡単になります。ただし、個人的には、そのような小さな利点に価値があるとは思いませんが、問題の Web アプリケーションに大きく依存します。
于 2009-09-23T01:56:02.363 に答える