Jak zbierać i wstrzykiwać wszystkie fasole danego typu w konfiguracji Spring XML

Question

Jednym z najsilniejszych akcentów struktury Spring jest koncepcja Dependency Injection. Rozumiem, że jedną z porad jest oddzielenie ogólnego mechanizmu wysokiego poziomu od szczegółów niskiego poziomu (zgodnie z zapowiedzią Dependency Inversion Principle).

Z technicznego punktu widzenia sprowadza się to do implementacji fasoli, aby wiedzieć jak mało o wstrzykiwaniu fasoli jako zależności, np.

public class PrintOutBean { 
    private LogicBean logicBean; 
    public void action() { 
     System.out.println(logicBean.humanReadableDetails()); 
    } 
    //... 
} 

<bean class="PrintOutBean"> 
    <property name="loginBean" ref="ShoppingCartBean"/> 
</bean> 

Ale co, gdybym chciał mieć mechanizm wysokiego poziomu działający na wielu zależnych ziarnach fasoli?

public class MenuManagementBean { 
     private Collection<Option> options; 
     public void printOut() { 
      for (Option option:options) { 
       // do something for option 
      } 
      //... 
     } 
    } 

wiem jedno rozwiązanie byłoby użyć @Autowired adnotacji w singleton fasoli, czyli ...

@Autowired 
    private Collection<Option> options; 

Ale nie to naruszać zasadę separacji? Dlaczego muszę określać, jakie zależności należy wybrać w tym samym miejscu, w którym je używam (np. MenuManagementBean w moim przykładzie)? Czy istnieje sposób na wstrzyknięcie kolekcji fasoli w konfiguracji XML w ten sposób (bez adnotacji w klasie MMB)?

<bean class="MenuManagementBean"> 
    <property name="options"> 
     <xxx:autowire by-type="MyOptionImpl"/> 
    </property> 
</bean> 

Answer 1

Nie ma gotowego urządzenia do tego, nie. Jednakże, jeśli chcesz sposobu zbierania wszystkich ziaren danego rodzaju w kolekcji, bez korzystania z listy @Autowired, to łatwo napisać zwyczaj FactoryBean to zrobić dla Ciebie:

public class BeanListFactoryBean<T> extends AbstractFactoryBean<Collection<T>> { 

    private Class<T> beanType; 
    private @Autowired ListableBeanFactory beanFactory; 

    @Required 
    public void setBeanType(Class<T> beanType) { 
     this.beanType = beanType; 
    } 

    @Override 
    protected Collection<T> createInstance() throws Exception { 
     return beanFactory.getBeansOfType(beanType).values(); 
    } 

    @Override 
    public Class<?> getObjectType() { 
     return Collection.class; 
    }  
} 

a następnie

<bean class="MenuManagementBean"> 
    <property name="options"> 
     <bean class="BeanListFactoryBean"> 
      <property name="beanType" class="MyOptionImpl.class"/> 
     </bean> 
    </property> 
</bean> 

Jednak to wszystko wydaje się być dużym wysiłkiem, aby uniknąć umieszczenia @Autowired w oryginalnej klasie. Nie ma to większego znaczenia z SoC, jeśli w ogóle jest - nie ma zależności compiltime i nie wiadomo skąd pochodzą options.

Answer 2

Alternatywa @Autowired, przy użyciu pliku kontekstowego: http://static.springsource.org/spring/docs/2.5.x/reference/beans.html#beans-factory-autowire

więc musiałbyś:

<bean class="MenuManagementBean" autowire="byType" /> 

Inne właściwości można określić jako normalne, a które mogłyby zastąpić autowiring tylko dla tych, nieruchomości.

Answer 3

Old pytanie wiosną 3.1 możliwe jest:

public class PluginPrototypeTest extends ASpringWebTest { 
    @Autowired 
    Collection<IDummyRepo> repos; 

    @Test 
    public void cacheTest() { 
    assertNotNull(repos); 
    assertEquals(2, repos.size()); 
    for(IDummyRepo r: repos){ 
     System.out.println(r.getName()); 
    } 
    } 
} 

@Repository 
public class DummyRepo implements IDummyRepo { 
    @Override 
    public String getName(){ 
    return "DummyRepo"; 
    } 
} 
@Repository 
public class DummyRepo2 implements IDummyRepo { 
    @Override 
    public String getName(){ 
    return "DummyRepo2"; 
    } 
}