さて、別の (@NoneScoped) Bean への参照を必要とする JSF バッキング Bean があります。
コンテナーからインスタンス参照を取得するには、@Inject または @ManagedProperty を使用する必要がありますか?
なぜ一方を使用して他方を使用しないのか、私の考えでは、2 つのアプローチは同じことを達成します。
さて、別の (@NoneScoped) Bean への参照を必要とする JSF バッキング Bean があります。
コンテナーからインスタンス参照を取得するには、@Inject または @ManagedProperty を使用する必要がありますか?
なぜ一方を使用して他方を使用しないのか、私の考えでは、2 つのアプローチは同じことを達成します。
@ManagedProperty
@NoneScoped
JSF 2.0仕様に由来@Inject
し、CDI仕様に由来します。
他の JavaEE 6 機能をまったく使用しないサーブレット アプリケーションで作業している場合は、@ManagedProperty
. その注釈には、に対しても利点があり@Inject
ます。EL(式言語)を使用できます(ただし、 CDI でそれを取得するための回避策があります)。
両方の注釈/コンテナーは「同じこと」を達成しているように見えますが、方法は大きく異なり、異なるコンテナーで動作します。CDI によって管理される Bean は JSF で使用できますが、その逆はできません。Bean に JSF 固有のアノテーションを付けている場合は、カスタム修飾子、インターセプター、プロデューサー メソッドなどの使用を忘れてください。最終的にはより洗練されているため、通常は CDI を使用したアプローチを好みますが、選択は実際のニーズによって異なります。 .
JSF機能を使用しているだけのように見えるので、まとめます(CDIは注釈を理解できません。CDI@ManagedProperty
@NoneScoped
では、指定されていない場合、すべてのBeanが@Default
スコープ内にあります)。プロジェクトで CDI に切り替えることは@ManagedProperty
、 1 つだけでなく、CDI 固有のもの@Inject
すべて(など) を置き換えることを意味する場合があります。@RequestScoped
可能な限り、マネージド Bean よりも CDI を優先します。CDI はデプロイ時の依存関係チェックが豊富で、そのプロキシ サポートによりスコープ リークが防止されます。これにより、モデルの正確性を簡単に検証できます。プロデューサーは通常、必要に応じてグルー コードを提供するために使用できます。