Comment éviter à l'aide de ApplicationContext.getBean() lors de la mise en œuvre de Printemps du CIO

Je suis juste de commencer avec le Printemps CIO concept. Je vois souvent la plupart des exemples trouvés dans l'internet d'utiliser le code pour obtenir l'objet.

ApplicationContext appContext = new ClassPathXmlApplicationContext("applicationContext.xml");
Hello hello = (Hello) appContext.getBean("hello");

Comme une référence à partir de ces questions Un et Deux dans le stackoverflow. J'en ai déduit qu'il n'est pas nécessaire d'utiliser appContext.getBean("bonjour") dans le code, qui est considéré comme de la mauvaise pratique. Aussi, pas recommandé plus. Corrigez-moi ici, Si mon inférence est faux.

Garder en vue, j'ai fait des changements dans mon projet en conséquence.
Voici mon applicationContext.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-3.2.xsd">
<bean id="utilClassRef" class="org.hd.derbyops.DUtils" lazy-init="false" />
<bean id="appContext" class="org.hd.derbyops.ContextProvider" lazy-init="false">
   <property name="utils" ref="utilClassRef" />
</bean>
</beans>

Mon contextProvider Code de la Classe

public class ContextProvider implements ApplicationContextAware {

    private static ApplicationContext ctx;

    /**
     * Objects as properties
     */
    private static DUtils utils;

    public void setApplicationContext(ApplicationContext appContext)
            throws BeansException {
        ctx = appContext;

    }

    public static ApplicationContext getApplicationContext() {
        return ctx;
    }

    public static DUtils getUtils() {
        return utils;
    }

    public void setUtils(DUtils dUtilsRef) {
        utils = dUtilsRef;
    }

}

Par exemple, considérons une classe qui dépend de org.hd.derbyops.DUtils.
Je suis en utilisant la ligne de code suivante

ContextProvider.getUtils();

afinde pour obtenir DUtils Objet dans la classe A, ainsi, éviter l'utilisation de ApplicationContext.getBean() partout dans mon code.

Assumer, si j'ai 10 classes et les élèves de ma classe A est dépendante sur chacun d'entre eux, dont les objets à créer et accéder sans l'aide de ApplicationContext.getBean(). Dans ce cas également, comme l'a fait ci-dessus, j'ai une pensée de la création de propriétés de ContextProvider classe, suivi par setter et getter de la propriété, où en get<PropertyName> est statique. Donc, je peux l'utiliser partout où je suis dans le besoin d'un objet, comme ce

ContextProvider.get<PropertyName>;

Voici ma brève question.
Tout d'abord, c'Est mon approche de droit? Si c'est à droite, le chargement de toutes les fèves à la start-up, ne serait-il pas un rendement tueur? Comment voudriez-vous faire cela dans vos applications sans appel getBean au moins plus d'une fois?

Si vous étiez à la conception d'une application web & vous avez été de mettre en œuvre le Printemps du CIO, sans l'aide de ApplicationContext.getBean() dans tout le code. Comment voudriez-vous faire cela?

Remarque: avec référence à d'autres questions tagged ci-dessus

Appel ApplicationContext.getBean() n'est pas d'Inversion de Contrôle!

Êtes-vous à l'aide de Spring MVC ou d'essayer de l'utilisation de base de servlets?
Je ne suis pas à l'aide de Spring MVC, je l'utilise juste pour le CIO
En général, quelqu'un est allez avoir besoin pour obtenir un de la fève de ApplicationContext. Idéalement, il ne doit être appelé qu'une seule fois, et il serait par le bootstrap de l'objet...

OriginalL'auteur srk | 2013-02-27

9

Les simples réponses sont oui et non, non et non. Et enfin, de faire une recherche en ligne pour spring MVC, comme c'est probablement ce qui fait ce que vous voulez.

Donc, votre approche. Oui, vous avez plus de droit. Cependant, il est considéré comme très mauvaise pratique d'utiliser des méthodes statiques pour tout. Et, vous n'avez pas besoin. Le printemps est basé sur l'idée que vous pouvez simplement créer normal pojo, et le printemps sera de les utiliser comme des singletons, et de les injecter dans l'un de l'autre (il peut aussi créer des objets à la volée, mais je vais pour la commune de la cas ici). Si vous utilisez les classes statiques et méthodes ensuite:
- Vous ne pouvez pas se moquer d'eux pour les tests unitaires (vous êtes en utilisant JUnit droit?)
- Vous ne pouvez pas les utiliser avec l'héritage
- Statique initialisers sont un excellent moyen de perdre des exceptions
- etc, etc
Donc, oui à l'injection, et non à la statique des choses.

Prochain, la performance. Vous avez raison en ce qu'il est beaucoup plus lent à utiliser le printemps, mais, si vous faites tout votre injection au démarrage il se produit seulement une fois. Le printemps est conçu pour des applications côté serveur où il y aura probablement un certain nombre de singleton classes de la transmission des données autour de. Donc, il y a peut-être une classe à avoir des trucs à partir d'une base, d'un processus, et l'une pour l'afficher, et le printemps est utilisé pour les fils ensemble.

Si vous êtes à l'aide de spring dans une application où vous commencez à plusieurs reprises, comme une application en ligne de commande, puis vous utilisez le mauvais type d'applications, et vous voudrez probablement utiliser un constructeur ou quelque chose. Le printemps est destiné pour les grandes applications de l'entreprise qui ne sont pas souvent redémarré.

Enfin, si vous avez simplement injecter toutes les dépendances pour une classe en au démarrage, et vous faites cela avec tous vos classes, alors vous n'avez pas besoin de faire un getBean choses à tous. Aussi, à l'aide de la init-method et destroy-method attributs sur un haricot signifie que vous pouvez démarrer des processus une fois que le printemps a fini de l'injection de dépendances. Vous avez seulement besoin de charger le contexte, et que votre application s'printemps (pun intended) dans l'existence.

Comme pour les projets web, Spring MVC prend l'ensemble de l'inversion de modèle de contrôle et l'applique à des applications web. Le printemps des trucs est chargé par le conteneur, et vous pouvez définir l'Url de répondre à l'aide de fèves de noms. Et la plupart de votre code peut rester pojo. Si vous avez quelque chose d'incroyablement complexe, vous voudrez peut-être chercher à spring web flow, mais je vous conseille de vous assurer que votre printemps foo est très fort avant de tenter cela.

En société, je n'ai jamais vu ApplicationContext.getBean() et d'autres choses. Mais c'est parce que ce sont le niveau de l'entreprise des applications web. Quels sont alors les charges jusqu'à toutes mes classes, pour moi? C'est le serveur qui est-il?
Normalement, vous utilisez l'un des pré-conserves de Printemps le chargement de l'application les classes, qui sont la norme JEE composants comme les servlets et autres joyeusetés. Ces puis le coup d'envoi de tous les printemps du CIO choses. Niché dans les entrailles de ces classes, il y aura un appel à créer le contexte de l'application à partir du fichier XML, l'associer à l'application en cours d'exécution, et de faire le contexte de l'application disponible dans certains.

OriginalL'auteur Jimadilo

Voici mon exemple pour l'obtention de la première instance sans appel getBean() sur ApplicationContext.

public class Test{
  //Declare private static variable so that we can access it in main()
  private static Triangle triangle;

  //Use constructor injection to set the triangle
  public Test(Triangle triangle) {
      Test.triangle = triangle;
  }

  public static void main(String[] args) {
      //Specify the context file containing the bean definitions
      //Spring automatically creates instances of all the beans defined
      //in this XML file. This process is performed before you actually make
      //a getBean("beanName") call.
      ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml");

      //Use instance methods of triangle 
      Test.triangle.draw();
  }
}

Vous pouvez utiliser un autre moyen:

Dans spring.xml (Votre bean fichier XML de configuration)

<bean class="com.example.Test" init-method="myMethod">
    <constructor-args ref="triangle"/>
</bean>

Maintenant pour votre classe principale

public class Test {
  private final Triangle triangle;

  public Test (Triangle triangle) {
     this.triangle = triangle;
  }

  public static void main (String[] args) {
     ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml");
  }

  //Called by Spring immediately after the Triangle Bean has been created and
  //all the properties for the bean have been set. This method name must match
  //the one specified with destroy-method attribute in spring.xml
  public void myMethod () {
     triangle.draw();
  }
}

OriginalL'auteur rIshab1988

Vous devez vous connecter pour publier un commentaire.