Core JavaServer Faces, 3rd Edを読み始めたところです。そして彼らはこれを言います（私のものを強調してください）：
JSF ページで使用できる Bean に、CDI Bean と JSF マネージド Bean という 2 つの別個のメカニズムがあることは、歴史的な偶然です。アプリケーションが Tomcat などのプレーン サーブレット ランナーで動作する必要がある場合を除き、CDI Bean を使用することをお勧めします。
なんで？彼らは何の正当性も提供しません。私は@ManagedBean、GlassFish 3 で実行されているプロトタイプ アプリケーションのすべての Bean に使用してきましたが、これに関する問題は特に気づいていません。@ManagedBeanからへの移行は特に気にしませんが、わざわざ に移行する理由を@Named知りたいです。
JSF 2.3に従って、@ManagedBeanは非推奨になりました。仕様の問題1417も参照してください。@ManagedBeanこれは、を選択する理由がもうないことを意味します@Named。これは、Mojarra2.3.0ベータバージョンm06で最初に実装されました。
主な違いは、 JSFフレームワークによって管理され、別のJSF管理対象Bean@ManagedBeanでのみ利用可能であるということです。CDIフレームワークを介してアプリケーションサーバー（コンテナ）によって管理され、、、、、、などのあらゆる種類のコンテナ管理アーティファクト、さらにはJSFでも利用できます。反対側からは、または他のコンテナ管理アーティファクトの内部では機能しません。それは実際には内部でのみ機能します。@ManagedProperty@Named@Inject@WebListener@WebFilter@WebServlet@Path@Stateless@ManagedBean@ManagedProperty@Named@ManagedBean
もう1つの違いは、CDIは、（EJBが注入される方法のように）要求/スレッドごとに、ターゲットスコープ内の現在のインスタンスに委任するプロキシを実際に注入することです。このメカニズムにより、範囲の狭いBeanを範囲の広いBeanに注入できます。これは、JSFでは不可能@ManagedPropertyです。JSFは、ここでセッターを呼び出すことによって物理インスタンスを直接「注入」します（これが、セッターが必要な理由でもありますが、では必要ありません@Inject）。
直接的な不利益ではありませんが（他の方法もあります）、範囲@ManagedBeanは単純に制限されています。別の見方をすれば、「あまりにも多く」を公開したくない場合は@Inject、管理対象Beanをそのままにしておくこともできます@ManagedBean。それはprotected対のようなものpublicです。しかし、それは実際には重要ではありません。
少なくとも、JSF 2.0 / 2.1では、JSFバッキングBeanをCDIで管理することの主な欠点は、に相当するCDIがないことです@ViewScoped。は@ConversationScoped近づいていますが、それでも手動で開始および停止する必要があり、cid結果のURLに醜いリクエストパラメータを追加します。MyFaces CODIを使用すると、JSFjavax.faces.bean.ViewScopedをCDIに完全に透過的にブリッジできるため、簡単に実行できます。ただし、単純なバニラページ間ナビゲーションでも、結果のURLに@Named @ViewScoped醜いリクエストパラメーターが追加されます。OmniFacesは、Beanのスコープを任意のリクエストパラメータではなくJSFビューステートに実際に結び付ける真のCDIを使用して、これをすべて解決します。windowId@ViewScoped
JSF 2.2（この質問/回答の3年後にリリースされます）は、@ViewScopedフレーバーのフレーバーで、箱から出して新しい完全にCDI互換の注釈を提供しますjavax.faces.view.ViewScoped。JSF 2.2に@FlowScopedは、同等のものがないCDIのみが付属しているため@ManagedBean、JSFユーザーはCDIに向かっています。Java EE 8に従って、および友人は非推奨になることが予想@ManagedBeanされます。したがって、現在もを使用している場合は@ManagedBean、将来のアップグレードパスに備えてCDIに切り替えることを強くお勧めします。CDIは、WildFly、TomEE、GlassFishなどのJava EEWebProfile互換のコンテナーですぐに利用できます。Tomcatの場合は、JSFの場合とまったく同じように、個別にインストールする必要があります。TomcatにCDIをインストールする方法も参照してください。
CDIはJavaEE全体の依存性注入を可能にするため、プレーンJSFよりもCDIが優先されます。POJOを挿入して管理させることもできます。JSFを使用すると、CDIで実行できるもののサブセットのみを注入できます。
Java EE 6 と CDI では、マネージド Bean のオプションが異なります
@javax.faces.bean.ManagedBeanJSR 314 を参照し、JSF 2.0 で導入されました。主な目標は、faces-config.xml ファイルの構成を回避して、JSF ページ内で Bean を使用することでした。@javax.annotation.ManagedBean(“myBean”)JSR 316 で定義されています。これは、Java EE の他の場所で使用するために JSF マネージド Bean を一般化します。@javax.inject.Named(“myBean”)上記とほぼ同じですが、CDI を有効にするために web/WEB-INF フォルダーに beans.xml ファイルが必要です。私は GlassFish 3.0.1 で CDI を使用していましたが、それを機能させるには、Seam 3 フレームワーク (Weld) をインポートする必要がありました。それはかなりうまくいきました。
GlassFish 3.1 では、CDI が機能しなくなり、Seam Weld が機能しなくなりました。これについてバグを開きましたが、まだ修正されていません。すべてのコードを javax.faces.* アノテーションを使用するように変換する必要がありましたが、機能するようになったら CDI に戻す予定です。
CDI を使用する必要があることに同意しますが、まだ解決されていない問題の 1 つは、@ViewScoped アノテーションをどうするかということです。それに依存するコードがたくさんあります。@ManagedBean を使用していない場合、 @ViewScoped が機能するかどうかは明確ではありません。誰かがこれを明確にできるなら、私はそれを感謝します。
CDI に移行する正当な理由の 1 つは、共通のセッション スコープのリソース (ユーザー プロファイルなど)@Injectを JSF マネージド Bean と REST サービス (つまり、Jersey/JAX-RS) の両方に含めることができることです。
一方、特に重要な AJAX を使用する場合@ViewScopedは、JSF に固執する説得力のある理由です。@ManagedBeanCDI には、これに代わる標準的なものはありません。
@ViewScopedCDI Bean の -like アノテーションをサポートしているようですが、個人的には試していません。