2010-02-03 3 views
4

** изменили пример, чтобы лучше выразить ситуациюВозможна ли Spring Autowire тот же экземпляр Protoype контекстного класса в двух местах

я использую весной 2.5 и имеют следующую ситуацию

@Component 
@Scope("prototype") 
Class Foo 
{ 
} 

class A 
{ 
    @Autowired 
    Foo fooA; 
} 


class B 
{ 
    @Autowired 
    Foo fooB; 
} 



class C 
{ 
    @Autowired 
    Foo fooC; 
} 

я пытаюсь понять, есть ли какой-то способ использовать @Autowired и связать один и тот же экземпляр FOO на fooA и fooB при связывании другого экземпляра fooC

я понимаю, что если объем FOO будет singleton он будет работать

, но я брожу, если есть способ достижения тех же целей при использовании protoype сферы.

также, пожалуйста, объясните это правильное использование концепции автопокрытия? я пытаюсь злоупотреблять целевым назначением весны

ответ

1

Весь смысл prototype scope заключается в том, что каждый раз вы получаете разные экземпляры.

Кроме того, автоподготовка фасонного прототипа сомнительна, конструктивна (на самом деле, я был бы слегка удивлен, если бы это было даже разрешено). Обычная идея состоит в том, чтобы автоподвести вместе бобы одного и того же масштаба (есть способы обойти это, но здесь не актуально).

Все, что связано с вашим дизайном, предполагает, что Foo не должен быть прототипом - зачем вы его сделали?

+0

приведенный выше пример является упрощенным выражением моей ситуации. Я использую компонент в форме прототипа, потому что он необходим в моей текущей конфигурации, есть много мест, где будет добавлен компонент и нужен новый экземпляр для каждого из них , , но есть конкретное место, где я хотел бы, чтобы два объекта разделили один и тот же экземпляр третьего объекта, и я хотел посмотреть, поддерживается ли он весной – Mark

+0

Возможно, вы можете настроить несколько однофунтовых фанов Foo и связать их индивидуально, используя '@Autowired @ Qualifier' – skaffman

1

Объекты, предназначенные для создания прототипов Autowiring, вполне возможны, но каждый раз создается новый экземпляр. Поэтому, чтобы ответить на ваш вопрос: нет, вы не можете этого сделать.

Ваше использование сканирования компонентов и автоустановки кажется приемлемым для другой части.

5

Поскольку ни singleton, ни prototype области не подходят для вас (вы не хотите, чтобы один объект, но вы не хотите, чтобы каждый экземпляр каждый раз), вам нужна другая область.

В контексте веб-приложения есть готовое решение - используйте область request - таким образом, в каждом цикле запроса/ответа у вас будет только один экземпляр вашего компонента, независимо от того, где и сколько раз вы его вводите.

В контексте без веб-приложений вы можете определить свою собственную реализацию org.springframework.beans.factory.config.Scope

Update: после прояснены, это кажется очень странным случае.То, что приходит мне на ум следующее:

  • определяют два FactoryBean с (на самом деле - подклассы AbstractFactoryBean) - один возвращение нового объекта каждый раз, и один возвращение того же объекта (оба должны быть в singleton объеме)
  • впрыснуть Foo с с @Resource(name="prototypeFactoryBean") и @Resource(name="singletonFactoryBean") (вместо @Autowired)
  • singletonFactoryBean могут быть разработаны, чтобы только вернуть синглтон (впрыскивается в классе завод фасоли)
  • prototypeFactoryBean может создать новый экземпляр, нанести BeanFactory (доступный через getBeanFactory()) на номер AutowireCapableBeanFactory и позвонить .autowire(newlyCreatedBean), а затем вернуть его. (В качестве альтернативы вы можете привнести в ApplicationContext и получить его AutowireCapableBeanFactory)

Но это слишком сложное, и вы будете нуждаться в углубленных знаниях пружинных даже после моего объяснения :)

Кроме того, я думаю, что вы должны пересмотреть свой дизайн вместо делая

Update, приведенную выше «причуды» 2: После вашего комментария, концепция именования передается аннотации - как я уже говорил выше, вы можете использовать @Resource(name="someBean")

+0

Я использую не-веб-конфигурацию, поэтому предлагаемое решение не применяется, также мое объяснение выше было упрощено, я пересмотрю его – Mark

+0

спасибо. Я согласен со всем, что вы сказали выше. я знаю, что это кажется странным сценарием, но если вы думаете об этом, в сложном проекте есть много случаев, когда несколько экземпляров определенного класса разделяются между другими классами. если вы думаете о весенней конфигурации XML, то она обрабатывается очень просто «именованием», вы просто определяете два компонента с разными именами, представленными одним и тем же «кодом». Я просто пытался проверить, была ли эта возможность передана аннотациям, кажется немного непоследовательным – Mark

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