異なる種類のJSFマネージドBeanを区別する

Question

私はこの記事を最近Neil Griffinから読みました異なる種類のJSF管理対象Beanを区別するで、自分のアプリケーションでの異なるBeanの違いについて考えました。要点を簡単に要約すると、

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

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

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

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

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

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

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

UserBeanはサポートマネージドBeanの例です。これはセッションスコープであり、Userクラスのインスタンス（認証されていない場合はnullになります）と、getterおよびsetterを備えています。

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

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

この方法は、懸念の分離に関して行う適切な方法でしょうか？

BalusC · Accepted Answer

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

モデルマネージドBean：このタイプのマネージドBeanは、MVC設計パターンの「モデル」の問題に参加します。「モデル」という言葉を目にしたら、DATAだと考えてください。 JSF model-beanは、getter/setterのカプセル化プロパティを持つJavaBean設計パターンに従うPOJOである必要があります。

マネージドBeanにしたり、管理したりすることは絶対にありません。 @ManagedBeanのプロパティにするだけです。たとえば、DTOまたはJPA @Entity。

マネージドBeanのバッキング：このタイプのマネージドBeanは、MVC設計パターンの「ビュー」問題に参加します。バッキングBeanの目的はUIロジックをサポートすることであり、JSFビュー、またはFaceletコンポジションのJSFフォームと1：1の関係にあります。通常、関連するゲッター/セッターを持つ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の状態に依存するジョブに対するものかどうかによって異なります。もしそうなら、彼らは豆に属しています。そうでない場合、それらは任意の FacesListener interface のスタンドアロン実装である必要がありますが、マネージドBeanではありません。

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

いいね。ドロップダウンリストなどのアプリケーション全体のデータの場合は@ApplicationScoped Beanを使用し、ログインユーザーやその設定などのセッション全体のデータの場合は@SessionScopedを使用します。

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

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

適切なアプローチのキックオフの例については、次も参照してください。