2009-05-12 11 views
3

Dire que j'ai deux classes A et B, avec B selon A.Comment gérer les dépendances dynamiques avec PicoContainer?

public class A {} 

public class B { 
    public B(A a) {} 
} 

Il est facile de résoudre B en une seule PicoContainer.

final MutablePicoContainer root = new PicoBuilder().build(); 
    root.addComponent(new A()); 
    root.addComponent(B.class, B.class); 
    System.out.println(root.getComponent(B.class)); 

Mais je voudrais avoir différentes instances de B pour différentes sessions, avec des instances variables de A. Je pense à quelque chose comme ça.

// during startup 
    final MutablePicoContainer root = new PicoBuilder().build(); 
    root.addComponent(B.class, B.class); 

    // later, initialize sessions 
    final MutablePicoContainer session = new PicoBuilder(root) 
     .implementedBy(TransientPicoContainer.class) 
     .build(); 
    session.addComponent(new A()); 

    // some request 
    System.out.println(session.getComponent(B.class)); 

code ci-dessus ne fonctionne pas, parce que lorsque vous demandez session un B il demande au conteneur parent root pour elle. B est trouvé là, mais résolu seulement dans root et ses parents, conduisant à UnsatisfiableDependenciesException.

Y at-il un bon moyen de faire ce travail? Ou est-ce un anti-pattern, et je résous le problème dans le mauvais sens?

+0

Vous devriez mieux utiliser Spring! C'est prouvé en affaires. Tellement de gens se sont permis avec une migration picoc => parce que le pico container était instable et buggy ... –

+3

Je ne suis pas d'accord. Pico est un * beaucoup * meilleur contenant que celui de Spring. L'avantage au printemps est sa communauté, pas sa technologie. – erickson

+0

@Ronald - Je ne comprends pas exactement quel est votre objectif. Voulez-vous créer un nouveau A et un nouveau B correspondant pour chaque session? Pourquoi ne pas utiliser votre modèle de "conteneur unique" pour enregistrer A et B dans le conteneur de session plutôt que dans la racine? – erickson

Répondre

0

Je voudrais également enregistrer B dans le conteneur de session. Toute autre dépendance de B que vous pouvez laisser dans le conteneur racine. Supposons que B a une autre dépendance sur C. Ainsi, vous pouvez effectuer les opérations suivantes:

// during startup 
final MutablePicoContainer root = new PicoBuilder().build(); 
root.addComponent(C.class, C.class); 

// later, initialize sessions 
final MutablePicoContainer session = new PicoBuilder(root) 
    .implementedBy(TransientPicoContainer.class) 
    .build(); 
session.addComponent(B.class, B.class); 
session.addComponent(new A()); 

// some request 
System.out.println(session.getComponent(B.class)); 
1

La résolution d'un problème de performance qui n'existe pas n'est pas une bonne approche. Avez-vous effectué un profilage pour vérifier le problème?

Sinon, pensez à le faire en premier.

+0

Cela semble vraiment se transformer en un mantra :) – willcodejavaforfood

1

Avez-vous activé la mise en cache sur votre conteneur (ou utilisez-vous 1.x Pico)?

Essayez de lire this, peut-être désactiver le cache est suffisant pour résoudre ce problème.

Questions connexes