JSF2を学んでいると、バッキングコンポーネントがどうあるべきかわからないことに気づきました。設計の観点から、EJBとの違いは何@ManagedBeansですか？
最終的にはJPAを使用するので、EJBはビジネスレイヤーにとって当然の選択です。（ここで説明されているように）JSFから直接EJBを使用することは良い習慣ですか？
@ManagedBeans現時点では、ビジネスレイヤーへのアクセス（ビューヘルパーなど）やリクエスト/セッションデータの処理を必要としないコンポーネントの使用に傾倒しています。他の目的、たとえばグリッドに何かをリストする場合、EJBに直接アクセスします。
これは良いデザインですか？@ManagedBeans場合によってはEJBにのみ委任する場合でも、クリーンなレイヤー分離のためにすべてのバッキングBeanに使用しますか？
非常に有効な質問ですが、答えはプロジェクトのアプローチの「厳密さ」に依存すると思います。JSFバッキングBeanとEJBはどちらもビジネスロジックを実装しているため、実際には少し冗長性があります。
、、などを使用したJSF機能の理想的な使用法では、バッキングBeanは確かにクリーンなビジネスロジックコードである可能性があります。しかし実際には、いくつかのプレゼンテーション関連のロジックが頻繁にリークします。convertersrenderedvalidator
このプレゼンテーション関連のロジックは、理想的にはEJBに含まれていてはなりません。このプレゼンテーション関連のロジックは、facesパッケージに依存する場合がありますが、必須ではありません。プレゼンテーションに関連するかどうかは、それが行うことです。
ただし、統合コンポーネントモデルにはいくつかの利点があります。そして、それはSeamとSpringが採用したアプローチです。どちらの場合も、宣言型トランザクションなどのビジネスコンポーネントをJSFで直接使用できます（SpringはEJBを使用しませんが、同様のモデルを提供します）。ただし、EJBの純粋主義者は、2つを分離する必要があると言います。
ですから、私にとっては、最終的にはプロジェクトの趣味と規模の問題です。JSFでEJBを使用する中小規模のプロジェクトでは、問題なく機能すると想像できます。この厳格さが重要な大規模なプロジェクトの場合は、レイヤーをねじ込まないようにしてください。
Java EE 6では、さまざまなマネージドBean（JSFマネージドBean（@ManagedBean）、CDIマネージドBean（@Named）、EJB Bean（@ Stateless、@ Statefull、@ Singleton））の間にいくつかの重複があります。
ビューレイヤーでは、@ManagedBeanを使用することに特に利点はありません。CDIバリアント@Namedは、同じ以上のことを実行できるようです。たとえば、変換スコープへのアクセスを提供します。
現在の考え方では、最終的にはEJBコンポーネントモデルもCDIアノテーションのセットとして後付けされると思われます。特に専門家グループのメンバーであるRezaRahmanは、これを頻繁にほのめかしています。たとえば、JavaEE6-パート1での依存性注入を参照してください。
当面はこれが発生していないため、EJB Beanは、特にJPAが永続性に使用される場合に、ビジネスロジックを配置する最も簡単な場所であり続けます。
それでも、CDIがEJBの機能を取得するかどうかにかかわらず、IMHOは、「バッキングBean」の概念に別のBeanを使用し、「ビジネスロジック」に別のBeanを使用することをお勧めします。
バッキングBeanは、モデルオブジェクトとサービス（EJB）への参照を含むだけで、非常にスリムにすることができます。バッキングBeanのアクションメソッドは、ほぼ直接サービスに委任できますが、その付加価値は、ユーザーにフィードバックを提供し（成功または失敗時にFacesMessagesを追加する）、UIを少し変更する（たとえば、ブール値をfalseに設定してダイアログを表示する）ことです。 。
サービス（ビジネスロジック）は、特定のプレゼンテーションについて何も知らないはずです。これらは、JSFバッキングBean、JAX-RS、サーブレット、スタンドアロンJavaSEリモートクライアントなどからも同様に使用できる必要があります。
すべてのBeanがCDIBeanになったとしても、これによってこの基本的な責任分担が変わることはありません。
興味深い記事、それについて知りませんでした。しかし、私には、この記事はJSFマネージドBeanに対する怒りのようなにおいがします。また、EJBとJSFを緊密に結合します。小さな（個人的な）アプリケーションでは興味深いかもしれませんが、EJBのサービスを完全に制御したい実際のSOAアプリケーションではおそらくそうではありません。
どちらを何に使用するかについて@ManagedBeanは、JSFモデルを示すために固執します。これは1つ以上の特定のJSFビューに関連付けられています。@EJBsは、JSF固有ではないビジネスロジックやデータモデルに完全に使用できます。JSFモデルにsを挿入@EJBし、アクションメソッドやゲッター/セッターに委任することもできますが、逆の方法で行うべきではありません。つまり、でJSFモデルを定義しないでください@EJB。これにより、密結合が発生し、@EJBsが作成されます。 JSFコンテキスト外では使用できません。これまでのところ、クラスjavax.facesのパッケージから何もインポートしないように注意している限り、デザインは良好に聞こえます。@EJB
XHTMLからEJBを呼び出すことにより、ビューでの実装の選択とビジネス層の間に緊密な結合が導入されます。
マネージドBeanを使用してEJBを呼び出す場合、またはビジネスデリゲートを配置する場合は、ビューレイヤー（XHTML）に影響を与えることなく、ビジネス層を完全にSpringに変更できます。
技術的に可能であり、（JSR 299）EJBをマネージドBeanとして使用できるようにするのは非常に簡単です。おそらく、これらのベンダーが望んでいることです。詳細に固執してください。しかし、それが正しいことであるかどうか？- いいえ。