Haricots de printemps à la coulée automatique

Question

Existe-t-il un moyen de convertir automatiquement les beans Spring dans la classe définie dans le contexte XML de l'application? J'aimerais éviter de mettre les informations de type sur les beans à deux endroits ... dans le fichier de configuration xml et également dans le code en tant que distribution.

Par exemple, étant donné ce fichier de configuration

<bean id="bean-name" class="SimpleSpringBean"  scope="prototype">
    <property name="myValue" value="simple value"></property>
</bean>

Puis-je appeler ApplicationContext.getBean ("nom-bean") de manière à éviter de transformer directement le type de retour en SimpleStringBean . Je sais que je peux aussi appeler ApplicationContext.getBean ("bean-name", SimpleSpringBean.class) pour éviter la diffusion elle-même, mais j'ai toujours le type d'informations à 2 endroits.

Il semble que Spring puisse obtenir les informations sur la classe ( ApplicationContext.getType ) ou en extrayant le type du bean lui-même, mais aucun moyen de le convertir automatiquement sans intervention du programmeur.

Answer 1

Je suis d'accord avec Sii, vous devriez éviter d'appeler getBean autant que vous le pouvez. Connectez simplement vos haricots aux classes qui en dépendent.

Néanmoins, si vous avez une seule classe contenant le contexte de l'application, vous pouvez fournir une méthode générique d'encapsuleur semblable à celle-ci:

class MyContextHolder{
    ApplicationContext appContext;
    ......
    @SuppressWarnings("unchecked")
    public static <T> T getBean(String beanName)
    {
        return (T)appContext.getBean(beanName);
    }
}

Ensuite, vous pouvez l'appeler sans lancer de casting

MyClass mc = MyContextHolder.getBean("myClassBean");

Answer 2

La réponse est que vous ne devriez pas utiliser ApplicationContext.getBean () du tout si cela est possible, et conserver le seul emplacement que vous devez avoir dans le code d’amorçage. (En règle générale, vous ne devriez jamais avoir besoin d'utiliser getBean () en dehors des points d'entrée de votre application.)

En outre, ce que vous demandez est probablement impossible en langage Java. Le casting est une fonctionnalité à la compilation, associée à une vérification à l'exécution. Le type de retour de getBean () doit simplement être connu au moment de la compilation. Même si Spring peut déterminer le type d'un objet, il ne peut pas modifier ses propres signatures de méthode au moment de l'exécution.

Autre chose, même si cela était possible, la fonctionnalité ne serait pas très utile. Spring AOP étant implémenté à l’aide de proxys dynamiques, vous souhaiterez presque toujours que Spring vous remette une instance d’une interface implémentée par le bean (qui pourrait être un proxy AOP), et non de la classe d’implémentation.

Answer 3

Une autre approche que j'utilise également est le câblage automatique de la classe d'amorçage à l'aide de:

public class Main {
    @Autowired FooFacade foo;
    @Autowired BarFacade bar;

    public static void main(String[] args) {
        ApplicationContext ctx = new ClassPathXmlApplicationContext("appCtx.xml");
        AutowireCapableBeanFactory bf = ctx.getAutowireCapableBeanFactory();
        Object main = bf.createBean(Main.class, 
                                    AutowireCapableBeanFactory.AUTOWIRE_AUTODETECT,
                                    false);
        ((Main) main).run();
    }

    private void run() {
        foo.doBootstrapStuff();
        bar.doMoreBootstrapStuff();
    }
}

(Code effectué depuis la mémoire. Ne fonctionne que si le contexte Spring est configuré pour traiter les annotations de câblage. Dans ce cas, la création de paramètres pour toto et barre devrait fonctionner. )

Answer 4

La principale raison de la suppression de la saisie de getBean est la compatibilité de Spring (jusqu'à la version 2.5.x) avec Java 1.4. Spring 3.0 abandonnera cela et offrira alors la méthode getBean typée.

Néanmoins, évitez de rechercher directement les haricots et limitez autant que possible leur utilisation.

Answer 5

Que se passe-t-il si j'utilise Spring en tant que fabrique d'objets que mon application utilise énormément? C'est, au lieu d'écrire un tas de classes qui héritent déjà ou enveloppent classes Java connues, je viens de décider de déplacer tout cela dans un fichier XML pour réduire lignes de code Java. Cela signifiera beaucoup de lignes de xml mais je n'aurai pas besoin de faire classes Java squelettiques que j’injecte avec Spring ou autowire. Faisant ainsi les lignes moins de code Java.

Pour cette raison, et toujours comme je suis nouveau au printemps, j’ai juste comme indiqué dans les précédents publications utilisées des méthodes Java statiques qui enveloppent getBeans ().

J'ai travaillé avec Spring, mais c'est encore nouveau pour moi, alors pardonnez ma question.

Answer 6

"Etant donné que Spring AOP est implémenté à l'aide de proxys dynamiques, vous souhaitez presque toujours que Spring vous remette une instance d'une interface implémentée par le bean (qui pourrait être un proxy AOP), pas de la classe d'implémentation"

Il n’existe donc aucun moyen d’obtenir un proxy dynamique à l’aide de getBean (). Quelle est donc la meilleure pratique en l’absence d’interfaces et qu’il s’agit d’une classe de pilotes autonome à exécuter?