私にとって、選択すべき主な違いは、すべての BeanBeanFactoryを事前にインスタンス化することです。春のドキュメントから：ApplicationContextApplicationContext
Spring は、Bean が実際に作成されたときに、できるだけ遅くプロパティを設定し、依存関係を解決します。つまり、正しくロードされた Spring コンテナーは、オブジェクトまたはその依存関係の作成に問題がある場合、オブジェクトを要求したときに後で例外を生成できます。たとえば、プロパティが見つからないか無効な場合、Bean は例外をスローします。このように一部の構成問題の可視性が遅れる可能性があるのは、デフォルトで ApplicationContext 実装がシングルトン Bean を事前にインスタンス化する理由です。これらの Bean を実際に必要になる前に作成するための事前の時間とメモリを犠牲にして、後でではなく、ApplicationContext が作成されたときに構成の問題を発見します。シングルトン Bean が事前にインスタンス化されるのではなく、遅延初期化されるように、このデフォルトの動作をオーバーライドすることもできます。
これを考慮して、BeanFactory分離された Bean をテストするためにアプリケーション全体をロードしたくなかったので、最初は統合/パフォーマンス テストで使用することを選択しました。ただし、間違っている場合は訂正してください。XML 構成BeanFactoryはサポートされていません。classpathしたがってBeanFactory、ApplicationContextそれぞれが私が望んでいた重要な機能を提供しますが、両方も提供しませんでした。
私が知る限り、デフォルトのインスタンス化動作のオーバーライドに関するドキュメントのメモは構成で行われ、それは Bean ごとであるため、XML ファイルに「lazy-init」属性を設定することはできません。テスト用と展開用のバージョンを維持するのに行き詰まりました。
私がやったのはClassPathXmlApplicationContext、次のようなテストで使用するためにBeanを遅延ロードするように拡張することでした:
public class LazyLoadingXmlApplicationContext extends ClassPathXmlApplicationContext {
public LazyLoadingXmlApplicationContext(String[] configLocations) {
super(configLocations);
}
/**
* Upon loading bean definitions, force beans to be lazy-initialized.
* @see org.springframework.context.support.AbstractXmlApplicationContext#loadBeanDefinitions(org.springframework.beans.factory.xml.XmlBeanDefinitionReader)
*/
@Override
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws IOException {
super.loadBeanDefinitions(reader);
for (String name: reader.getBeanFactory().getBeanDefinitionNames()) {
AbstractBeanDefinition beanDefinition = (AbstractBeanDefinition) reader.getBeanFactory().getBeanDefinition(name);
beanDefinition.setLazyInit(true);
}
}
}