7

私は、次のテクノロジーを組み合わせようとしている Java webapp に取り組んでいます。

  • JavaEE6
  • CDI
  • JSF2
  • EJB 3.1
  • 春のセキュリティ

JSF ページに CDI ベースのバッキング Bean (@ViewScoped、@Named) を提供しています。

実際の作業には @Stateless EJB Bean を使用します。

jSessionCookie (コンテナーによって管理される)、内部ユーザー名、その他の内部 ID などのいくつかのセッション情報のみが必要です。さて、JSF のバッキング Bean でアクセスできるだけでなく、ステートレス EJB にも提供できるように、このセッション情報をどこに配置すればよいのでしょうか。@Stateful EJB セッション Bean を使用する必要がありますか、それとも @SessionScoped と @Named を使用して CDI ベースの POJO を作成する必要がありますか?

ベストプラクティスはありますか?

4

2 に答える 2

8

特定のユース ケースでは、ステートフル セッション Bean は適切な選択ではありません。

人々が主張するかもしれないことに反して、ステートフル セッション Bean は一般的に避けるべきものではないことに注意してください。ただし、これらは高度なユースケース用です。たとえば、JPA の拡張永続コンテキストを処理する場合などです。

ここでステートフル セッション Bean が機能しない理由は、それらが HTTP セッションに自動的に関連付けられないためです。それらに @SessionScoped アノテーションを追加することもできますが、通常のマネージド Bean を使用することもできます。SFSB の特定の機能は使用しません。

参照:

セッション スコープの CDI Bean を使用してステートレス EJB を注入できますが、同じアプリケーション内で EJB Bean が HTTP セッションに依存することを認識する必要があります (たとえば、Bean を呼び出さなければならない場合など、これを避けたい場合があります)。他の文脈からも）。

于 2012-08-21T21:05:53.330 に答える
2

@Stateful EJB は避けたいものです。振る舞いと状態は混同してはいけないものだと思います。

私もSJuan76の答えに行き、SessionScoped JSFバッキングBeanを使用します。

于 2012-08-21T19:42:56.240 に答える