BeanFactory vs ApplicationContext

Je suis assez nouveau dans Spring Framework, j'ai joué avec lui et assemblé quelques exemples d'applications dans le but d'évaluer Spring MVC pour une utilisation dans un projet d'entreprise à venir. Jusqu'à présent, j'aime vraiment ce que je vois dans Spring MVC, semble très facile à utiliser et vous encourage à écrire des classes qui sont très faciles à tester.

Juste comme exercice, j'écris une méthode principale pour l'un de mes projets d'échantillons / tests. Une chose dont je ne suis pas certain, c'est les différences exactes entre BeanFactoryet ApplicationContext- ce qui est approprié à utiliser dans quelles conditions?

Je comprends que cela ApplicationContexts'étend BeanFactory, mais si j'écris simplement une méthode principale simple, ai-je besoin de la fonctionnalité supplémentaire ApplicationContextfournie? Et quel type de fonctionnalité supplémentaire ApplicationContextoffre exactement ?

En plus de répondre "qui dois-je utiliser dans une méthode main ()", existe-t-il des normes ou des directives concernant l'implémentation à utiliser dans un tel scénario? Est-ce que ma méthode main () doit être écrite pour dépendre de la configuration du bean / application au format XML - est-ce une hypothèse sûre, ou suis-je en train de verrouiller l'utilisateur dans quelque chose de spécifique?

Et cette réponse change-t-elle dans un environnement Web - si l'une de mes classes devait connaître Spring, est-elle plus susceptible d'en avoir besoin ApplicationContext?

Merci pour toute aide. Je sais que beaucoup de ces questions trouvent probablement une réponse dans le manuel de référence, mais j'ai du mal à trouver une ventilation claire de ces deux interfaces et les avantages / inconvénients de chacune sans lire le manuel avec un peigne à dents fines.

Les documents de printemps sont excellents à ce sujet: 3.8.1. BeanFactory ou ApplicationContext? . Ils ont un tableau avec une comparaison, je vais poster un extrait:

Usine de haricots

• Instanciation / câblage du bean

Contexte d'application

• Instanciation / câblage du bean
• Enregistrement automatique de BeanPostProcessor
• Enregistrement automatique de BeanFactoryPostProcessor
• Accès pratique à MessageSource (pour i18n)
• Publication ApplicationEvent

Donc, si vous avez besoin de l'un des points présentés du côté du contexte d'application, vous devez utiliser ApplicationContext.

Le printemps fournit deux types de conteneurs IOC, l'un est XMLBeanFactoryet l'autre l'est ApplicationContext.

+---------------------------------------+-----------------+--------------------------------+
|                                       | BeanFactory     |       ApplicationContext       |
+---------------------------------------+-----------------+--------------------------------+
| Annotation support                    | No              | Yes                            |
| BeanPostProcessor Registration        | Manual          | Automatic                      |
| implementation                        | XMLBeanFactory  | ClassPath/FileSystem/WebXmlApplicationContext|
| internationalization                  | No              | Yes                            |
| Enterprise services                   | No              | Yes                            |
| ApplicationEvent publication          | No              | Yes                            |
+---------------------------------------+-----------------+--------------------------------+

• FileSystemXmlApplicationContext Haricots chargés à travers le chemin complet.
• ClassPathXmlApplicationContext Haricots chargés via le CLASSPATH
• XMLWebApplicationContextet les AnnotationConfigWebApplicationContextbeans chargés via le contexte de l'application Web.
• AnnotationConfigApplicationContext Chargement des beans Spring à partir d'une configuration basée sur des annotations.

exemple:

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(BeansConfiguration.class);

• ApplicationContextest le conteneur initialisé par a ContextLoaderListenerou ContextLoaderServletdéfini dans a web.xmlet ContextLoaderPlugindéfini dans struts-config.xml.

Remarque : XmlBeanFactoryest déconseillé à partir du printemps 3.1 en faveur de DefaultListableBeanFactoryet XmlBeanDefinitionReader.

Pour moi, la principale différence de choisir BeanFactoryplus ApplicationContextsemble être que ApplicationContextsera pré-instancier tous les haricots. À partir des documents du printemps :

Spring définit les propriétés et résout les dépendances le plus tard possible, lorsque le bean est réellement créé. Cela signifie qu'un conteneur Spring qui s'est chargé correctement peut générer ultérieurement une exception lorsque vous demandez un objet s'il y a un problème lors de la création de cet objet ou de l'une de ses dépendances. Par exemple, le bean lève une exception en raison d'une propriété manquante ou non valide. Cette visibilité potentiellement retardée de certains problèmes de configuration explique pourquoi les implémentations ApplicationContext par défaut pré-instancient les beans singleton. Au prix d'un temps et d'une mémoire initiaux pour créer ces beans avant qu'ils ne soient réellement nécessaires, vous découvrez des problèmes de configuration lors de la création d'ApplicationContext, pas plus tard. Vous pouvez toujours remplacer ce comportement par défaut afin que les beans singleton soient initialisés paresseux, plutôt que d'être pré-instanciés.

Compte tenu de cela, j'ai d'abord choisi BeanFactoryd'utiliser les tests d'intégration / de performance car je ne voulais pas charger l'application entière pour tester les beans isolés. Cependant - et quelqu'un me corrige si je me trompe - BeanFactoryne prend pas en charge la classpathconfiguration XML. Donc, BeanFactoryet ApplicationContextchacun fournit une fonctionnalité cruciale que je voulais, mais les deux non plus.

Autant que je sache, la note dans la documentation sur le remplacement du comportement d'instanciation par défaut a lieu dans la configuration, et c'est par bean, donc je ne peux pas simplement définir l'attribut "lazy-init" dans le fichier XML ou je suis bloqué en conservant une version pour le test et une pour le déploiement.

Ce que j'ai fini par faire était d'étendre le ClassPathXmlApplicationContextchargement de haricots paresseux à utiliser dans des tests comme celui-ci:

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);
        }
    }

}

Pour ajouter à ce que Miguel Ping a répondu, voici une autre section de la documentation qui y répond également:

Version courte: utilisez un ApplicationContext sauf si vous avez une très bonne raison de ne pas le faire. Pour ceux d'entre vous qui recherchent un peu plus de profondeur quant au «mais pourquoi» de la recommandation ci-dessus, continuez à lire.

(poster ceci pour tous les futurs novices du printemps qui pourraient lire cette question)

1. ApplicationContext est plus préférable que BeanFactory

2. Dans les nouvelles versions Spring BeanFactoryest remplacé par ApplicationContext. Mais BeanFactoryexiste toujours pour la compatibilité descendante

3. ApplicationContext extends BeanFactory et présente les avantages suivants
   • il prend en charge l'internationalisation des messages texte
   • il prend en charge la publication d'événements aux auditeurs enregistrés
   • l'accès aux ressources telles que les URL et les fichiers

ApplicationContext: Il charge les beans Spring configurés dans le fichier de configuration Spring et gère le cycle de vie du Spring Bean au fur et à mesure du démarrage du conteneur. Il n'attendra pas que getBean ("springbeanref") soit appelé.

BeanFactory Il charge beans printemps configurés dans le fichier de configuration du ressort, gère le cycle de vie de la fève de printemps , quand nous appelons le getBean ( « springbeanref ») .Donc lorsque nous appelons le getBean ( « springbeanref ») au moment de cycle de vie de haricots printemps commence .

Je pense qu'il est préférable de toujours utiliser ApplicationContext, sauf si vous êtes dans un environnement mobile comme quelqu'un l'a déjà dit. ApplicationContext a plus de fonctionnalités et vous voulez certainement utiliser les PostProcessors tels que RequiredAnnotationBeanPostProcessor, AutowiredAnnotationBeanPostProcessor et CommonAnnotationBeanPostProcessor, qui vous aideront à simplifier vos fichiers de configuration Spring, et vous pouvez utiliser des annotations telles que @Required, @PostConstruct, @Resource, etc. .

Même si vous n'utilisez pas tout ce que propose ApplicationContext, il est préférable de l'utiliser de toute façon, puis plus tard si vous décidez d'utiliser des ressources telles que des messages ou des post-processeurs, ou l'autre schéma pour ajouter des conseils transactionnels et autres, vous aura déjà un ApplicationContext et n'aura pas besoin de changer de code.

Si vous écrivez une application autonome, chargez ApplicationContext dans votre méthode principale, à l'aide d'un ClassPathXmlApplicationContext, et obtenez le bean principal et appelez son run () (ou toute autre méthode) pour démarrer votre application. Si vous écrivez une application Web, utilisez le ContextLoaderListener dans web.xml afin qu'il crée l'ApplicationContext et que vous puissiez ensuite l'obtenir à partir du ServletContext, que vous utilisiez JSP, JSF, JSTL, Struts, Tapestry, etc. .

Rappelez-vous également que vous pouvez utiliser plusieurs fichiers de configuration Spring et vous pouvez soit créer ApplicationContext en répertoriant tous les fichiers dans le constructeur (ou en les répertoriant dans le paramètre de contexte pour ContextLoaderListener), ou vous pouvez simplement charger un fichier de configuration principal qui a déclarations d'importation. Vous pouvez importer un fichier de configuration Spring dans un autre fichier de configuration Spring en utilisant <import resource = "otherfile.xml" />, ce qui est très utile lorsque vous créez par programmation ApplicationContext dans la méthode principale et chargez un seul fichier de configuration Spring.

Pour la plupart, ApplicationContext est préférable, sauf si vous devez enregistrer des ressources, comme sur une application mobile.

Je ne suis pas sûr de dépendre du format XML, mais je suis presque sûr que les implémentations les plus courantes d'ApplicationContext sont celles XML telles que ClassPathXmlApplicationContext, XmlWebApplicationContext et FileSystemXmlApplicationContext. Ce sont les trois seuls que j'ai jamais utilisés.

Si vous développez une application Web, il est sûr de dire que vous devrez utiliser XmlWebApplicationContext.

Si vous souhaitez que vos beans soient au courant de Spring, vous pouvez les faire implémenter BeanFactoryAware et / ou ApplicationContextAware pour cela, vous pouvez donc utiliser BeanFactory ou ApplicationContext et choisir l'interface à implémenter.

Les différences entre BeanFactory et ApplicationContext sont les suivantes:

1. BeanFactory utilise une initialisation paresseuse mais ApplicationContext utilise une initialisation rapide . Dans le cas de BeanFactory, le bean est créé lorsque vous appelez la méthode getBeans (), mais le bean est créé en amont dans le cas d'ApplicationContext lorsque l'objet ApplicationContext est créé.
2. BeanFactory fournit explicitement un objet ressource à l'aide de la syntaxe mais ApplicationContext crée et gère les objets ressource de lui-même.
3. BeanFactory ne prend pas en charge l'internationalisation, mais ApplicationContext prend en charge l'internationalisation.
4. Avec BeanFactory, l'injection de dépendances basée sur les annotations n'est pas prise en charge, mais l' injection de dépendances basée sur les annotations est prise en charge dans ApplicationContext.

Utilisation de BeanFactory:

BeanFactory beanfactory = new XMLBeanFactory(new FileSystemResource("spring.xml"));
 Triangle triangle =(Triangle)beanFactory.getBean("triangle");

Utilisation d'ApplicationContext:

ApplicationContext context = new ClassPathXMLApplicationContext("spring.xml")
Triangle triangle =(Triangle)context.getBean("triangle");

BeanFactory et ApplicationContext sont tous deux des moyens d'obtenir des haricots à partir de votre conteneur IOC de printemps , mais il existe toujours des différences.

BeanFactory est le conteneur réel qui instancie, configure et gère un certain nombre de beans. Ces beans collaborent généralement entre eux et ont donc des dépendances entre eux. Ces dépendances se reflètent dans les données de configuration utilisées par BeanFactory.

BeanFactory et ApplicationContext sont tous deux des interfaces Java et ApplicationContext étend BeanFactory. Les deux sont configurés à l'aide de fichiers de configuration XML. En bref, BeanFactory fournit des fonctionnalités basiques d'inversion de contrôle ( IoC ) et d'injection de dépendance ( DI ) tandis qu'ApplicationContext fournit des fonctionnalités avancées .

Une BeanFactory est représentée par l'interface " org.springframework.beans.factory " où BeanFactory, pour laquelle il existe plusieurs implémentations.

ClassPathResource resource = new ClassPathResource("appConfig.xml");
XmlBeanFactory factory = new XmlBeanFactory(resource);

DIFFÉRENCE

1. BeanFactory instancie le bean lorsque vous appelez la méthode getBean () tandis que ApplicationContext instancie le bean Singleton lorsque le conteneur est démarré, il n'attend pas que getBean () soit appelé.

2. BeanFactory ne fournit pas de support pour l'internationalisation mais ApplicationContext le fournit.

3. Une autre différence entre BeanFactory et ApplicationContext est la possibilité de publier un événement sur des beans enregistrés comme écouteur.

4. XMLBeanFactory est l'une des implémentations populaires de l' interface BeanFactory, tandis que l'une des implémentations populaires de l' interface ApplicationContext est ClassPathXmlApplicationContext .

5. Si vous utilisez le câblage automatique et utilisez BeanFactory, vous devez enregistrer AutoWiredBeanPostProcessor à l' aide de l'API que vous pouvez configurer en XML si vous utilisez ApplicationContext . En résumé, BeanFactory est OK pour les tests et l'utilisation hors production, mais ApplicationContext est une implémentation de conteneur plus riche en fonctionnalités et doit être privilégiée par rapport à BeanFactory

6. BeanFactory supporte par défaut son chargement paresseux et ApplicationContext supporte par défaut un chargement agressif .

Matrice des fonctionnalités de Bean Factory vs contexte d'application provenant de documents de printemps

_{Capture d'écran des fonctionnalités de BeanFacotry et ApplicationContext}

une. Une différence entre la fabrique de bean et le contexte d'application est que l'ancien bean instancie uniquement lorsque vous appelez la méthode getBean () tandis que ApplicationContext instancie le bean Singleton lorsque le conteneur est démarré.Il n'attend pas que getBean soit appelé.

b.

ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml");

ou

ApplicationContext context = new ClassPathXmlApplicationContext{"spring_dao.xml","spring_service.xml};

Vous pouvez utiliser un ou plusieurs fichiers xml en fonction des besoins de votre projet. Comme j'utilise ici deux fichiers xml, c'est-à-dire un pour les détails de configuration des classes de service, l'autre pour les classes dao. Ici, ClassPathXmlApplicationContext est enfant d'ApplicationContext.

c. BeanFactory Container est un conteneur de base, il ne peut que créer des objets et injecter des dépendances. Mais nous ne pouvons pas attacher d'autres services comme la sécurité, les transactions, la messagerie, etc. pour fournir tous les services dont nous disposons pour utiliser ApplicationContext Container.

ré. BeanFactory ne prend pas en charge l'internationalisation, c'est-à-dire i18n, mais ApplicationContext le prend en charge.

e. BeanFactory Container ne prend pas en charge la fonctionnalité d'AutoScanning (Support Annotation based dependency Injection), mais ApplicationContext Container prend en charge.

F. Beanfactory Container ne créera pas d'objet bean avant l'heure de la demande. Cela signifie que Beanfactory Container charge les grains paresseusement. Alors que ApplicationContext Container crée des objets de bean singleton au moment du chargement uniquement. Cela signifie qu'il y a un chargement précoce.

g. Beanfactory Container ne prend en charge que deux portées (singleton et prototype) des beans. Mais ApplicationContext Container prend en charge toute la portée des beans.

Fondamentalement, nous pouvons créer un objet conteneur à ressort de deux façons

1. en utilisant BeanFactory.
2. en utilisant ApplicationContext.

les deux sont les interfaces,

en utilisant des classes d'implémentation, nous pouvons créer un objet pour le conteneur à ressort

venir aux différences

BeanFactory:

1. Ne prend pas en charge l'injection de dépendances basée sur les annotations.

2. Ne prend pas en charge I18N.

3. Par défaut, il prend en charge le chargement paresseux.

4. il ne permet pas de configurer plusieurs fichiers de configuration.

ex: contexte BeanFactory = nouveau XmlBeanFactory (nouvelle ressource ("applicationContext.xml"));

ApplicationContext

1. Prise en charge de la dépendance basée sur les annotations Injection.-@Autowired, @PreDestroy

2. Prise en charge I18N

3. Par défaut, il prend en charge le chargement agressif.

4. Il permet de configurer plusieurs fichiers de configuration.

ex:
contexte ApplicationContext = nouveau ClasspathXmlApplicationContext ("applicationContext.xml");

Reportez-vous à ce document de Spring Docs:

http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/beans.html#context-introduction-ctx-vs-beanfactory

5.15.1 BeanFactory ou ApplicationContext?

Utilisez un ApplicationContext sauf si vous avez une bonne raison de ne pas le faire.

Étant donné que ApplicationContext inclut toutes les fonctionnalités de BeanFactory, il est généralement recommandé par rapport à BeanFactory, à l'exception de quelques situations comme dans une applet où la consommation de mémoire peut être critique et quelques kilo-octets supplémentaires peuvent faire la différence. Cependant, pour la plupart des applications et systèmes d'entreprise typiques, ApplicationContext est ce que vous voudrez utiliser. Spring 2.0 et versions ultérieures font un usage intensif du point d'extension BeanPostProcessor (pour effectuer un proxy et ainsi de suite). Si vous utilisez uniquement un BeanFactory ordinaire, une bonne quantité de support, comme les transactions et l'AOP, ne prendra pas effet, du moins pas sans quelques étapes supplémentaires de votre part. Cette situation pourrait être déroutante car rien n'est réellement mauvais avec la configuration.

ApplicationContext est un grand frère de BeanFactory et tout cela serait fourni par BeanFactory et bien d'autres choses.

Outre les capacités de cycle de vie org.springframework.beans.factory.BeanFactory standard, les implémentations ApplicationContext détectent et appellent les beans ApplicationContextAware ainsi que les beans ResourceLoaderAware, ApplicationEventPublisherAware et MessageSourceAware.

Dans un scénario en temps réel, la différence entre le conteneur Spring IOC Core (BeanFactory) et le conteneur Advanced J2EE (ApplicationContext) est la suivante.

1. BeanFactory créera des objets pour les beans (c'est-à-dire pour les classes POJO) mentionnés dans le fichier spring.xml ( <bean></bean>) uniquement lorsque vous appelez la méthode .getBean (), mais alors que ApplicationContext crée les objets pour tous les beans ( <bean></bean>si sa portée n'est pas explicitement mentionné comme "Prototype") configuré dans le fichier spring.xml lors du chargement du fichier spring.xml lui-même.

2. BeanFactory: (conteneur paresseux car il crée les objets pour les beans uniquement lorsque vous appelez explicitement à partir de la classe user / main)

   /*
    * Using core Container - Lazy container - Because it creates the bean objects On-Demand
    */
   //creating a resource
   Resource r = (Resource) new ClassPathResource("com.spring.resources/spring.xml");
   //creating BeanFactory 
   BeanFactory factory=new XmlBeanFactory(r);
   
   //Getting the bean for the POJO class "HelloWorld.java"
   HelloWorld worldObj1 = (HelloWorld) factory.getBean("test");

   ApplicationContext: (conteneur désireux en raison de la création des objets de tous les beans singleton lors du chargement du fichier spring.xml lui-même)

   ApplicationContext context = new ClassPathXmlApplicationContext("com/ioc/constructorDI/resources/spring.xml");

3. Techniquement, l'utilisation d'ApplicationContext est recommandée car dans les applications en temps réel, les objets bean seront créés pendant le démarrage de l'application sur le serveur lui-même. Cela réduit le temps de réponse à la demande de l'utilisateur car les objets sont déjà disponibles pour répondre.

Je pense qu'il convient de mentionner que depuis le printemps 3, si vous voulez créer une usine, vous pouvez également utiliser l' @configurationannotation combinée avec la bonne@scope

@Configuration
public class MyFactory {

    @Bean
    @Scope("prototype")
    public MyClass create() {
        return new MyClass();
    }
}

Votre usine doit être visible par le conteneur Spring en utilisant l' @ComponentScanannotation ou la configuration xml

Article sur les haricots de printemps du site de Baeldung

utilisez BeanFactory pour les applications non Web car il ne prend en charge que les étendues de bean Singleton et Prototype.

Alors que le conteneur ApplicationContext prend en charge toutes les étendues de bean, vous devez donc l'utiliser pour des applications Web.

En résumé:

Le ApplicationContext inclut toutes les fonctionnalités du BeanFactory. Il est généralement recommandé d'utiliser le premier.

Il existe certaines situations limitées, comme dans une application mobile, où la consommation de mémoire peut être critique.

Dans ces scénarios, il peut être justifié d'utiliser le BeanFactory plus léger . Cependant, dans la plupart des applications d'entreprise, ApplicationContext est ce que vous voudrez utiliser.

Pour en savoir plus, consultez mon article de blog:

Différence entre BeanFactory et ApplicationContext in Spring - Le blog du printemps java des bases

J'ai besoin d'expliquer le BeanFactory & ApplicationContext.

BeanFactory: BeanFactory est l'interface racine pour accéder au conteneur SpringBean. Il existe une vue client de base d'un conteneur de bean. Cette interface est implémentée par la classe d'objets qui contient le nombre de définitions de beans, et chacune est identifiée de manière unique par le nom de chaîne.
En fonction de la définition du bean, la fabrique renvoie l'instance, cette instance peut être l'instance de l'objet contenu ou une seule instance partagée. Le type d'instance qui sera renvoyé dépend de la configuration de l'usine de bean.
Normalement, Bean Factory chargera la définition de tous les beans, qui est stockée dans la source de configuration comme XML ... etc.

BeanFactory est un conteneur le plus simple fournissant le support de base pour l'injection de dépendance

Contexte d' application Le contexte d'application est une interface centrale avec dans l'application Spring qui fournit les informations de configuration à l'application. Il implémente l'interface Bean Factory.

Le contexte d'application est un conteneur avancé qui ajoute un niveau avancé de fonctionnalités spécifiques à l'entreprise telles que la capacité de résoudre le message textuel à partir du fichier de propriétés, etc., etc.

Un ApplicationContext fournit:

Méthodes Bean Factory pour accéder aux composants de l'application. Hérité de ListableBeanFactory. La possibilité de charger des ressources de fichiers de manière générique. Hérité de l'interface ResourceLoader. La possibilité de publier des événements pour les auditeurs enregistrés. Hérité de l'interface ApplicationEventPublisher. La capacité de résoudre des messages, de soutenir l'internationalisation. Hérité de l'interface MessageSource. Héritage d'un contexte parent. Les définitions dans un contexte descendant seront toujours prioritaires. Cela signifie, par exemple, qu'un seul contexte parent peut être utilisé par une application Web entière, tandis que chaque servlet a son propre contexte enfant qui est indépendant de celui de tout autre servlet. En plus des capacités de cycle de vie standard de BeanFactory,