Как управлять динамическими зависимостями с помощью PicoContainer?

Скажем, у меня есть два класса А и В, с В зависимости от А.Как управлять динамическими зависимостями с помощью PicoContainer?

public class A {} 

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

Это легко решить B в одном PicoContainer.

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

Но я хотел бы иметь разные экземпляры B для различных сессий, с переменными экземплярами 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));

Приведенный выше код не работает, потому что, когда просят session для B он запрашивает родительский контейнер root для него. B, но разрешен только в пределах root и его родителей, что приводит к UnsatisfiableDependenciesException.

Есть ли хороший способ сделать эту работу? Или это анти-шаблон, и я решу проблему не так?

источник

2009-05-12 Ronald Blaschke

Лучше использовать весну! Это дело доказано. Так много людей могут позволить себе picoc => весеннюю миграцию, потому что контейнер pico был нестабильным и багги ... –

Я не согласен. Пико - это гораздо лучший контейнер, чем весна. Преимущество весны - это его сообщество, а не его технология. – erickson

@ Ronald - Я не совсем понимаю, в чем ваша цель. Вы хотите, чтобы для каждого сеанса был создан новый A и соответствующий новый B? Почему бы не использовать шаблон «одного контейнера» для регистрации A и B в контейнере сеанса, а не в корне? – erickson

Я бы зарегистрировал B в контейнере сеанса. Любая другая зависимость B, которую вы можете оставить в корневом контейнере. Пусть B имеет другую зависимость от C. Таким образом, вы можете сделать следующее:

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

источник

2009-06-04 08:35:35 ordnungswidrig

Решение проблемы производительности, которая не существует, не является хорошим подходом. Прошли ли какие-либо профилирования, чтобы проверить проблему?

Если нет, подумайте об этом.

источник

2009-05-14 12:50:22

Это действительно похоже на мантру :) – willcodejavaforfood

ли вы включить кэширование на контейнере (или вы используете Pico 1.x)?

Попробуйте прочитать this, возможно, отключение кеша достаточно, чтобы решить эту проблему.

источник

2009-06-05 11:15:01

Как управлять динамическими зависимостями с помощью PicoContainer?

ответ

Смежные вопросы