BeanFactory API

BeanFactory API は、Spring の IoC 機能の基礎を提供します。その特定の契約は、Spring の他の部分および関連するサードパーティフレームワークとの統合で主に使用され、その DefaultListableBeanFactory 実装は、高レベルの GenericApplicationContext コンテナー内の主要なデリゲートです。

BeanFactory および関連インターフェース(BeanFactoryAwareInitializingBeanDisposableBean など)は、他のフレームワークコンポーネントの重要な統合ポイントです。アノテーションやリフレクションさえも必要としないことで、コンテナーとそのコンポーネント間の非常に効率的な相互作用が可能になります。アプリケーションレベルの Bean は同じコールバックインターフェースを使用する場合がありますが、通常はアノテーションまたはプログラムによる構成のいずれかを使用して、代わりに宣言依存性注入を優先します。

コア BeanFactory API レベルとその DefaultListableBeanFactory 実装は、使用される構成形式やコンポーネントアノテーションについて想定していないことに注意してください。これらのフレーバーはすべて、拡張機能(XmlBeanDefinitionReader や AutowiredAnnotationBeanPostProcessor など)を通じて提供され、コアメタデータ表現として共有 BeanDefinition オブジェクトを操作します。これは、Spring のコンテナーを非常に柔軟で拡張可能にするものの本質です。

BeanFactory または ApplicationContext

このセクションでは、BeanFactory コンテナーレベルと ApplicationContext コンテナーレベルの違いとブートストラップへの影響について説明します。

GenericApplicationContext とそのサブクラス AnnotationConfigApplicationContext をカスタムブートストラップの一般的な実装として使用する理由がない限り、ApplicationContext を使用する必要があります。これらは、構成ファイルのロード、クラスパススキャンのトリガー、Bean 定義とアノテーション付きクラスのプログラムによる登録、および(5.0 以降)関数 Bean 定義の登録など、すべての一般的な目的のための Spring のコアコンテナーへの主要なエントリポイントです。

ApplicationContext には BeanFactory のすべての機能が含まれているため、Bean 処理の完全な制御が必要なシナリオを除き、プレーンな BeanFactory よりも一般的に推奨されます。ApplicationContext (GenericApplicationContext 実装など)では、いくつかの種類の Bean が慣例(つまり、Bean 名または Bean 型、特にポストプロセッサー)によって検出されますが、プレーン DefaultListableBeanFactory は特別な Bean に依存しません。

アノテーション処理や AOP プロキシなど、多くの拡張コンテナー機能には、BeanPostProcessor 拡張ポイントが不可欠です。プレーンな DefaultListableBeanFactory のみを使用する場合、そのようなポストプロセッサーはデフォルトでは検出およびアクティブ化されません。Bean の設定に実際に問題はないため、この状況は混乱を招く可能性があります。むしろ、このようなシナリオでは、追加のセットアップによりコンテナーを完全にブートストラップする必要があります。

次の表に、BeanFactory および ApplicationContext のインターフェースと実装が提供する機能を示します。

表 1: 機能マトリックス
フィーチャー BeanFactoryApplicationContext

Bean のインスタンス化 / 接続

はい

はい

統合されたライフサイクル管理

いいえ

はい

自動 BeanPostProcessor 登録

いいえ

はい

自動 BeanFactoryPostProcessor 登録

いいえ

はい

便利な MessageSource アクセス (国際化のために)

いいえ

はい

ビルトイン ApplicationEvent 発行メカニズム

いいえ

はい

Bean ポストプロセッサーを DefaultListableBeanFactory に明示的に登録するには、次の例に示すように、プログラムで addBeanPostProcessor を呼び出す必要があります。

  • Java

  • Kotlin

DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
// populate the factory with bean definitions

// now register any needed BeanPostProcessor instances
factory.addBeanPostProcessor(new AutowiredAnnotationBeanPostProcessor());
factory.addBeanPostProcessor(new MyBeanPostProcessor());

// now start using the factory
val factory = DefaultListableBeanFactory()
// populate the factory with bean definitions

// now register any needed BeanPostProcessor instances
factory.addBeanPostProcessor(AutowiredAnnotationBeanPostProcessor())
factory.addBeanPostProcessor(MyBeanPostProcessor())

// now start using the factory

BeanFactoryPostProcessor をプレーンな DefaultListableBeanFactory に適用するには、次の例に示すように、postProcessBeanFactory メソッドを呼び出す必要があります。

  • Java

  • Kotlin

DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
reader.loadBeanDefinitions(new FileSystemResource("beans.xml"));

// bring in some property values from a Properties file
PropertySourcesPlaceholderConfigurer cfg = new PropertySourcesPlaceholderConfigurer();
cfg.setLocation(new FileSystemResource("jdbc.properties"));

// now actually do the replacement
cfg.postProcessBeanFactory(factory);
val factory = DefaultListableBeanFactory()
val reader = XmlBeanDefinitionReader(factory)
reader.loadBeanDefinitions(FileSystemResource("beans.xml"))

// bring in some property values from a Properties file
val cfg = PropertySourcesPlaceholderConfigurer()
cfg.setLocation(FileSystemResource("jdbc.properties"))

// now actually do the replacement
cfg.postProcessBeanFactory(factory)

どちらの場合も、明示的な登録手順は不便です。そのため、Spring-Backed アプリケーションでは、特に BeanFactoryPostProcessor および BeanPostProcessor インスタンスに依存して、一般的なエンタープライズセットアップで拡張されたコンテナー機能を使用する場合、さまざまな ApplicationContext バリアントがプレーン DefaultListableBeanFactory よりも優先されます。

AnnotationConfigApplicationContext にはすべての一般的なアノテーションポストプロセッサーが登録されており、@EnableTransactionManagement などの構成アノテーションを通じてカバーに追加のプロセッサーを取り込むことができます。Spring のアノテーションベースの構成モデルの抽象化レベルでは、Bean ポストプロセッサーの概念は単なる内部コンテナーの詳細になります。