2

セッション スコープとリクエスト スコープに関して、JSF マネージド Bean を実装する最良の方法は何だと思いますか? 私の場合、EJB モジュールと Web モジュールを備えた EAR アプリケーションがあります。EJB モジュールは、ステートレス セッション Bean を提供します。Web モジュールでは、sessionScope で ManagedBean を使用しています。この Bean は、いくつかのステーレス セッション ejb を注入し、さまざまなページで使用できるビジネス データを含むいくつかの値オブジェクトを保持します。

@Named("workflowController")
@SessionScoped
public class WorkflowController {
    private List<ItemCollection> someList;
    private ItemCollection someBusinessData;
    /* Services */
    @EJB
    private MyService myService;

この Bean は、フロントエンドに多くのアクション メソッドを提供し、ステートレス セッション Bean を利用します。これは一般的な良い習慣ですか？または、コントローラーを要求スコープに変更する必要がありますか? フロントエンド コントローラーが RequestScoped でのみ使用され、すべてのビジネス データ オブジェクトを、SessionScope で ManagedBeans として実装される managedProperties として注入するプロジェクトを見てきました。

私の例では、すべてのビジネス値を保持し、ステートレス ejb に実装されたビジネス メソッドを提供する、SessionScope 内のコントローラーが 1 つだけあります。他のケースでは、RequestScopde で 1 つのコントローラーが使用され、コントローラー Bean に注入される SessionScope で MangedBeans として実装された多くの BusinessValue オブジェクトがあります。

私の質問は次のとおりです: 一般に、Session EJB を SessionScope Managed Bean に注入するのは悪い習慣ですか?

4

1 に答える 1

5

セッション スコープのマネージド Bean がビジネス ロジックにアクセスする必要がある場合、それにステートレス EJB を注入することは悪い習慣ではありません。

セッション スコープの Bean を過度に使用することは、悪い習慣となる可能性があります。

セッション スコープ Bean は、現在ログインしているユーザーやショッピング カートに関する詳細など、HTTP セッションにとって真にグローバルなものにのみ使用してください。ユーザーがブラウザーで複数のウィンドウまたはタブを開くたびに、セッション スコープ Bean が競合状態になる可能性があることに注意してください。

数十から数百のページを持つ典型的な Web アプリケーションでは、ほとんどの場合、ほんの一握りのセッション スコープ Bean しか存在しないはずです。

単一のページをサポートするマネージド Bean (バッキング Bean と呼ばれる) の場合、多くの場合、ビュー スコープが JSF で最も適切なスコープです。ページが正確に何をするかに応じて、リクエストスコープも適切な場合があります。経験則として、ページが最初に要求されたときにデータがロードされ、ポストバック後にも必要になる場合は、ビュー スコープを使用します。そのようなデータがない場合は、リクエスト スコープを回避できるかどうか試してください。

一種のフローで複数のページにまたがる必要がある場合、既に永続化されていてそれらの ID を渡すことができるデータに関係する場合は、GET パラメーターを介してデータを渡すことを選択できます。それ以外の場合は、会話のスコープを調べたい場合があります。

残念ながら、JSF 2.1 以前は CDI マネージド Bean のビュー スコープをネイティブにサポートしていませんが、CODI などのサード パーティ プロジェクトは実装を提供しています (JSF 2.2 は、そのままで CDI のビュー スコープをサポートする可能性が高いです)。

于 2012-09-07T22:26:03.933 に答える