5

私はショッピング カート スタイルのプロセスで JSF を使用して Java EE Web アプリを開発しているので、多数のページでユーザー入力を収集し、それを使って何かをしたいと考えています。

これには EJB 3 ステートフル セッション Bean を使用することを考えていましたが、調査の結果、SFSB はクライアントの http セッションに関連付けられていないため、httpSession を介して手動で追跡する必要があると思われます。ここ 。. .

1) セッション Bean と呼ばれるのはなぜですか。私が見る限り、セッションとは何の関係もありません。セッションに pojo を格納することで同じことを達成できます。

2) 注入できるということのポイントは何ですか?もし注入するのがこの SFSB の新しいインスタンスだけなら、pojo を使用したほうがよいでしょうか?

JSF はプレゼンテーション テクノロジであるため、ロジックに使用するべきではありませんが、ユーザー入力を収集するための最適なオプションのように思われます。

JSF セッション スコープ Bean をすべてのリクエスト Bean の管理プロパティとして設定できます。つまり、それらに注入されますが、SFSB とは異なり、JSF マネージド セッション スコープ Bean は http セッションに関連付けられているため、同じインスタンスが常に次のように注入されます。 http セッションが無効化されていない限り。

だから私は複数の層を持っています

第 1 層) プレゼンテーションを処理する JSF マネージド リクエスト スコープ Bean。ページごとに 1 つ。
第 2 層) 要求 Bean によって設定された値を持つ JSF 管理セッション スコープ Bean。
第 3 層) JSF セッション スコープ Bean 内のデータに対してロジックを実行するステートレス セッション EJB。

なぜこれがそんなに悪いのですか？

代替オプションは SFSB を使用することですが、それを最初のリクエスト Bean に挿入し、それを http セッションに格納して、後続の各リクエスト Bean で取得する必要があります。

または、すべてをセッションに保存することもできますが、リテラル キーとキャストを使用する必要があるため、これは理想的ではありません。など .. エラーが発生しやすいなど。. . そして乱雑！

私は、このテクノロジーに取り組んでいるというよりは、このテクノロジーと戦っているように感じます。

ありがとう

4

3 に答える 3

9

セッション Bean と呼ばれる理由は、セッションとは何の関係もないことがわかる限り、pojo をセッションに格納することで同じことを実現できます。

古いJ2EE 1.3 チュートリアルから:

セッション Bean とは

セッション Bean は、J2EE サーバー内の単一のクライアントを表します。サーバーにデプロイされたアプリケーションにアクセスするために、クライアントはセッション Bean のメソッドを呼び出します。セッション Bean はクライアントのために作業を実行し、サーバー内でビジネス タスクを実行することによってクライアントを複雑さから保護します。

その名前が示すように、セッション Bean は対話型セッションに似ています。セッション Bean は共有されません。対話型セッションに 1 人のユーザーしかいないのと同じように、セッション Bean には 1 つのクライアントしかありません。対話型セッションと同様に、セッション Bean は永続的ではありません。(つまり、そのデータはデータベースに保存されません。) クライアントが終了すると、そのセッション Bean は終了したように見え、クライアントに関連付けられなくなります。

つまり、「セッション」に関係しています。ただし、セッションは必ずしも「HTTP セッション」を意味するわけではありません

私が注入するのがこの SFSB の新しいインスタンスだけである場合、それを注入できることのポイントは何ですか?

まず第一に、ステートレス コンポーネントに SFSB を注入しないでください (別の SFSB に注入しても問題ありません)。ルックアップを行う必要があります。次に、HTTP セッションと SFSB のどちらを選択するかは、アプリケーションとニーズによって異なります。純粋に理論的な観点から、HTTP セッションはプレゼンテーション ロジックの状態 (たとえば、マルチ ページ フォームのどこにいるか) に使用し、SFSB はビジネス ロジックの状態に使用する必要があります。これは、TSS の「古い」HttpSession 対ステートフル セッション Beanスレッドでうまく説明されており、SFSB が理にかなっている良い例もあります。

ステートフル セッション Bean を使用して、特定のトランザクションの状態を追跡したい場合があります。つまり、鉄道の切符を購入する人です。

Web セッションは、ユーザーが HTML ページ フローのどこにいるかの状態を追跡します。ただし、ユーザーが別のチャネル (例: wap phone) またはコール センターを介してシステムにアクセスした場合でも、チケット購入トランザクションの状態を知りたいと思うでしょう。

しかし、SFSB は単純ではありません。その使用を正当化する必要がない場合は、HTTP セッションを使用することをお勧めします (特に、これらすべてが初めての場合)。念のため、次を参照してください。

JSF はプレゼンテーション テクノロジであるため、ロジックに使用するべきではありませんが、ユーザー入力を収集するための最適なオプションのように思われます。

それはビジネス ロジックではなく、プレゼンテーション ロジックです。

だから私は複数の層を持っています (...)

いいえ。おそらく、クライアント層、プレゼンテーション層、ビジネス層、データ層があります。あなたが説明しているものは、レイヤーのように見えます（確かではありません）。見る：

なぜこれがそんなに悪いのですか？

わかりません、あなたが何について話しているのかわかりません:)しかし、おそらくマルチページフォーム情報をSessionScoped Beanに収集し、プロセスの最後にステートレスセッションBean（SLSB）を呼び出す必要があります。

于 2010-09-02T23:57:03.070 に答える
6

1) セッション Bean と呼ばれるのはなぜですか。私が見る限り、セッションとは何の関係もありません。セッションに pojo を格納することで同じことを達成できます。

訂正: EJB セッションは HTTP セッションとは何の関係もありません。EJB では、クライアントはサーブレット コンテナーであり、サーバーは EJB コンテナーです (どちらも Web/アプリケーション サーバーで実行されます)。HTTP では、クライアントは Web ブラウザーであり、サーバーは Web/アプリケーション サーバーです。

今はもっと理にかなっていますか？

2）それを注入できるということのポイントは何ですか。注入するのがこのSFSBの新しいインスタンスだけである場合、pojoを使用することもできますか？

トランザクション ビジネス タスクには EJB を使用します。セッション スコープのマネージド Bean を使用して、HTTP セッション固有のデータを格納します。ちなみに、どちらもPOJOではありません。ただのJavabeans。

ロジックに JSF SessionScoped Bean を使用してはいけないのはなぜですか?

トランザクション ビジネス タスクを利用しておらず、EJB が提供する抽象化を活用していない場合は、単純な JSF マネージド Bean でそれを実行するだけでも、悪い選択肢ではありません。これは、基本的な JSF アプリケーションの通常のアプローチでもあります。ただし、アクションは通常、リクエスト スコープのマネージド Bean で実行され、セッション スコープのマネージド Bean は として注入されます@ManagedProperty。

しかし、あなたは既に EJB を使用しているのですから、EJB を使用する特別な理由がなかったかどうかは疑問です。それが有利なビジネス要件である場合、私はそれに固執します。少なくとも、セッションの混乱は解消されるはずです。

于 2010-09-02T17:14:38.877 に答える
2

これに気付いていない場合に備えて、回答へのわずかな貢献として、実際に@SessionScopedでSFSBに注釈を付けることができ、CDIがEJBのライフサイクルを処理します...これはEJBを結び付けますCDIが管理するHttpセッションに移動します。あなたの質問であなたが言うので、あなたに知らせるだけです：

but my research leads me to believe that a SFSB is not tied to a client's http session, so I would have to manually keep track of it via an httpSession, some side questions here . . .

また、提案したことを実行することもできますが、要件によって異なります。CDIBeanが宣言型トランザクションのサポートや拡張永続コンテキストなどを取得するまでは、Beanのクリーン度を下げる多くの定型コードを記述していることに気付くでしょう。もちろん、Seam（現在はDeltaSpikeに移行）などのフレームワークを使用して、拡張機能を通じてBeanの特定の機能を強化することもできます。

ですから、そうだと思います。一見、ステートフルEJBを使用する必要はないと感じるかもしれませんが、特定のユースケースはそれらを介してより適切に解決できる場合があります。ユーザーが自分のカートに商品を追加し、別のユーザーが後でこの同じ商品を追加したが、在庫が1つしかない場合、誰がそれを入手しますか？チェックアウトを速くする人は？またはそれを最初に追加した人？ユーザーがブラウザーをランダムに閉じることを決定した場合に、エンティティマネージャーにアクセスしてカートを永続化する場合、または複数のページを生成するトランザクションがあり、すべてのステップをデータベースに同期させる場合はどうなりますか？（トランザクションを長時間開いたままにすることはお勧めできませんが、これが必要になるシナリオがあるかもしれませんか？）SLSBを使用することもできますが、SFSBを使用する方が適切でクリーンな場合もあります。

于 2012-11-17T03:35:17.537 に答える