CDI (およびその実装 Weld) のおかげで、JEE6 のすべての POJO に のアノテーションを付けることができ@Named、POJO をビューからアクセスできるようになります。
つまり、ManagedBeans は完全に時代遅れになったということですか? それとも、@ManagedBeanまだ意味のある何かを見逃したのでしょうか?
ベストアンサー1
つまり、@ManagedBeanJSF を使用するが JSR 299 を使用しないアプリケーション (理由が何であれ) には意味があります。以下は Gavin King による詳しい説明です。
Re: JSF2 の @ManagedBean アノテーションとの比較?:
Weld の例と古い WebBeans ドキュメントを見ると、新しい @ManagedBean JSF 2.0 アノテーションの競合製品のように見えます。どちらを使用するのがよいかに関する情報はありますか?
それは良い質問です、そして私はこれまで投稿された回答に完全に同意しているわけではありません。
新しい EE Managed Beans 仕様では、Java EE の基本コンポーネント モデルと、非常に基本的なコンテナー サービス セット (
@Resource、、) が定義されています。@PostConstruct@PreDestroy他の仕様 (EJB、CDI、JSF、新しい Java Interceptors 仕様から始まる) は、この基本コンポーネント モデルに基づいて構築され、トランザクション管理、タイプセーフな依存性注入、インターセプターなどの追加サービスをレイヤー化するという考えです。したがって、このレベルでは、マネージド Bean、CDI、インターセプター、および EJB 仕様はすべて連携して動作し、非常に補完的です。
現在、マネージド Beans 仕様は、どのクラスがマネージド Beans であるかを正確に識別することに関しては、かなりオープンエンドです。1
@ManagedBeanつのメカニズムとしてアノテーションを提供していますが、他の仕様で異なるメカニズムを定義することもできます。たとえば、次のようになります。
@StatelessEJB 仕様では、EJB jar にデプロイされたまたはアノテーションを使用して特定のプログラミング制限に従うクラスは@Statefulマネージド Bean であるとされています。CDI 仕様では、「Bean デプロイメント アーカイブ」にデプロイされた適切なコンストラクターを持つクラスはすべてマネージド Bean であるとされています。
EJB と CDI はマネージド Bean を識別するためのより便利な方法を提供しているため、具体的に何が
@ManagedBean必要なのか疑問に思うかもしれません。Dan が示唆しているように、その答えは、環境内で CDI が利用できる場合 (たとえば、EE6 を使用している場合)、@ManagedBean実際には必要ありません。@ManagedBeanCDIなしでJSF2を使用している人が使用するために存在します。一方、Beanに注釈を付け
@ManagedBean、環境にCDIがある場合は、CDIを使用してBeanに何かを注入することができます。注釈@ManagedBeanが必須この場合。要約する、CDIを利用できる場合は、遠いJSF2 が JSF1 から継承した
@ManagedBean/モデルよりも優れたプログラミング モデル@ManagedProperty実際には、非常に優れているため、EE 6 Web プロファイルでは etc のサポートは必要ありません@ManagedProperty。代わりに CDI を使用する必要があるという考えです。