46

私は最近、Neil Griffinがさまざまな種類のJSFマネージドBeanを区別することからこの記事を読み、自分のアプリケーションでのさまざまなBeanの区別について考えさせられました。要点をすばやく要約するには：

  • モデルマネージドBean：このタイプのマネージドBeanは、MVCデザインパターンの「モデル」の問題に関与します。「モデル」という言葉を目にしたときは、DATAと考えてください。JSFモデルBeanは、プロパティをカプセル化するゲッター/セッターを備えたJavaBeanデザインパターンに従うPOJOである必要があります。

  • Managed-Beanのバッキング：このタイプのManaged-Beanは、MVCデザインパターンの「ビュー」の問題に関与します。バッキングBeanの目的は、UIロジックをサポートすることであり、JSFビューまたはFaceletコンポジションのJSFフォームと1：1の関係にあります。通常、ゲッター/セッターが関連付けられたJavaBeanスタイルのプロパティがありますが、これらはビューのプロパティであり、基になるアプリケーションデータモデルのプロパティではありません。JSFバッキングBeanには、JSFactionListenerメソッドとvalueChangeListenerメソッドも含まれる場合があります。

  • Controller Managed-Bean：このタイプのManaged-Beanは、MVCデザインパターンの「Controller」の問題に関与します。コントローラBeanの目的は、ある種のビジネスロジックを実行し、ナビゲーション結果をJSFナビゲーションハンドラに返すことです。JSFコントローラーBeanには通常、JSFアクションメソッドがあります（actionListenerメソッドはありません）。

  • マネージドBeanのサポート：このタイプのBeanは、MVCデザインパターンの「ビュー」に関する1つ以上のビューを「サポート」します。典型的な使用例は、複数のJSFビューに表示されるJSF h：selectOneMenuドロップダウンリストにArrayListを提供することです。ドロップダウンリストのデータがユーザーに固有のものである場合、Beanはセッションスコープに保持されます。

  • ユーティリティ管理対象-Bean：このタイプのBeanは、1つ以上のJSFビューにある種の「ユーティリティ」機能を提供します。この良い例は、複数のWebアプリケーションで再利用できるFileUploadBeanです。

これは私にとって理にかなっており、過去数時間、コードをリファクタリングしていて、ユーザーログインに関して次のことを思いついた。

これAuthenticationControllerは、ControllerManaged-Beanの例です。これはリクエストスコープであり、ユーザー名とパスワードを設定するための2つのゲッターとセッター、および2つのナビゲーション方法を備えauthenticateておりlogout、ログインに成功するとプライベートエリアに移動するか、ログアウトするとメインページに戻ります。

これUserBeanは、サポート管理対象Beanの例です。これはセッションスコープでありUser、ゲッターとセッターを備えたクラスのインスタンス（認証されていない場合はnullになります）を備えています。

はAuthenticationController、このユーザーを管理プロパティ（@ManagedProperty(value = "#{userController.user} private User user;）として持っています。認証が成功すると、AuthenticationControllerは管理プロパティを、ログインに使用された対応するユーザー名を持つ実際のユーザーインスタンスに設定します。

Userクラスにグループ名のリストが含まれている場合、新しいBeanはすべて、ユーザーを管理プロパティとして取得し、必要なデータ（たとえば、グループメンバーシップなど）を取得できます。

この方法は、関心の分離に関して進むための適切な方法でしょうか？

4

1 に答える 1

90

これは非常に主観的な質問です。私は個人的にその記事に反対であり、初心者に本当に悪いアドバイスを与えていることがわかりました.

モデル マネージド Bean: このタイプのマネージド Bean は、MVC 設計パターンの「モデル」に関与します。「モデル」という言葉を目にしたら、データを思い浮かべてください。JSF モデル Bean は、プロパティをカプセル化するゲッター/セッターを備えた JavaBean デザイン パターンに従う POJO である必要があります。

私はそれを管理対象のBeanにしたり、呼び出したりすることは絶対にありません。のプロパティにするだけ@ManagedBeanです。たとえば、 DTO または JPA @Entity。

バッキング マネージド Bean: このタイプのマネージド Bean は、MVC 設計パターンの「ビュー」に関与します。バッキング Bean の目的は、UI ロジックをサポートすることであり、Facelet コンポジションの JSF ビューまたは JSF フォームと 1::1 の関係があります。通常、関連付けられた getter/setter を持つ JavaBean スタイルのプロパティがありますが、これらはビューのプロパティであり、基礎となるアプリケーション データ モデルのプロパティではありません。JSF バッキング Bean には、JSF actionListener および valueChangeListener メソッドも含まれる場合があります。

このようにして、マネージド Bean 内のエンティティのプロパティを複製およびマッピングし続けます。これは私には意味がありません。前述のように、エンティティをマネージド Bean のプロパティにして、入力フィールドが の#{authenticator.user.name}代わりに直接参照できるようにし#{authenticator.username}ます。

コントローラー管理対象 Bean: このタイプの管理対象 Bean は、MVC 設計パターンの「コントローラー」の問題に参加します。コントローラー Bean の目的は、ある種のビジネス ロジックを実行し、ナビゲーションの結果を JSF ナビゲーション ハンドラーに返すことです。通常、JSF コントローラ Bean には JSF アクション メソッドがあります (actionListener メソッドはありません)。

これは@RequestScoped/@ViewScoped @ManagedBeanクラスをかなり説明しています。イベントリスナーメソッドが許可されるかどうかは、それらが Bean に関連付けられているビューに固有のものであるか、および/または Bean の状態に依存するジョブ用であるかによって異なります。そうである場合、それらは Bean に属します。そうでない場合、それらは任意のFacesListenerインターフェースのスタンドアロン実装である必要がありますが、マネージド Bean ではないことは間違いありません。

マネージド Bean のサポート: このタイプの Bean は、MVC 設計パターンの「ビュー」に関する 1 つ以上のビューを「サポート」します。典型的な使用例は、複数の JSF ビューに表示される JSF h:selectOneMenu ドロップダウン リストに ArrayList を提供することです。ドロップダウン リストのデータがユーザー固有のものである場合、Bean はセッション スコープに保持されます。

罰金。ドロップダウン リストなどのアプリケーション全体のデータには@ApplicationScopedBean を使用し、ログイン ユーザーやその設定などのセッション全体のデータには 1 つだけを使用します@SessionScoped。

Utility Managed-Bean: このタイプの Bean は、1 つ以上の JSF ビューにある種の「ユーティリティ」機能を提供します。この良い例は、複数の Web アプリケーションで再利用できる FileUpload Bean です。

これは私にはあまり意味がありません。通常、バッキング Bean は単一のビューに関連付けられています。これは、選択したコマンド コンポーネントActionListenerで使用される実装のように思えます。<f:actionListener>間違いなく管理対象の Bean ではありません。

正しいアプローチのキックオフ例については、以下も参照してください。

于 2011-08-28T20:58:47.750 に答える