Как точно настроить конфигурацию Proxies на основе Spring Inheritance?

Question

Я изучаю сертификацию Spring Core, и я нахожу некоторые сомнения, связанные с прокси.

Так на учебный материал я найти следующий тест:

Существует Ява конфигурации класса, который содержит следующие методы:

@Bean 
public AccountRepository accountRepository(){ 
    return new JdbcAccountRepository(); 
} 

@Bean 
public TransferService transferService1() { 
    TransferServiceImpl service = new TransferServiceImpl(); 
    service.setAccountRepository(accountRepository()); 
    return service; 
} 

@Bean 
public TransferService transferService2() { 
    return new TransferServiceImpl(new JdbcAccountRepository()); 
} 

Как вы можете видеть Есть 2 разные реализации a transferService(), соответственно, названный transferService1() и transferService2(), которые создают и возвращают TransferServiceImpl объект.

Первый creatre новый TransferServiceImpl объект и затем вызвать setAccountRepository() метод на нем.

Второй просто создать TransferServiceImpl передавая новый объект JdbcAccountRepository в конструктор.

Он спрашивает меня ** Какая из лучших двух предыдущих методов?

И ответ предоставляется: Предпочитаете вызов специальному методу. Поэтому я думаю, что он говорит, что лучший способ - это первая реализация.

Он объясняет, что AccountRepository боб является одноточечно (потому что это стандартный комплект для фасоли весной), но что JdbcAccountRepository() можно назвать дважды или несколько раз (например, в предыдущем фрагмент кода он вызывается при вызове методов transferService1() и transferService2() и если это так, что это будет проблемой, потому что AccountRepository должны быть одноточечно.

Это правда? Или я чего-то не хватает?

Так я понял, что в момент времени класса конфигурации Еогеаспа запуска (с аннотацией @Configuration) создается класс с ребенком, который расширяет мой класс конфигурации.

Например, если я следующий класс конфигурации:

@Configuration 
public class AppConfig { 
    @Bean public AccountRepository accountRepository() { ... } 
    @Bean public TransferService transferService() { ... } 
} 

он автоматически создается следующий класс, который расширяет мой AppConfig:

public class AppConfig$$EnhancerByCGLIB$ extends AppConfig { 
    public AccountRepository accountRepository() { // ... } 
    public TransferService transferService() { // ... } 
    ... 
    ... 
    ... 
} 

Так класс ребенок является точка входа (метод называется те, которые определены в дочернем классе), а псевдокод будет примерно таким:

public class AppConfig$$EnhancerByCGLIB$ extends AppConfig { 

    public AccountRepository accountRepository() { 
     // if bean is in the applicationContext return bean 
     // else call super.accountRepository() and store bean in context 
    } 

    public TransferService transferService() { 
     // if bean is in the applicationContext, return bean 
     // else call super.transferService() and store bean in context 
    } 
} 

Так появляется довольно ясно, как Spring может справиться с одноплодной проблемой: это называют методы на прокси-классе, который расширяет класс конфигурации, и если запрашиваемый боб существовать в ApplicationContext вернуть эту фасоль, еще называют то же самое метод суперкласса, который создает новый компонент и помещает его в контекст приложения.

Это правильный смысл наследования, основанный на шаблоне прокси, или я что-то упускаю?

Answer 1

Да, что вы описали в основном, как Spring handles @Configuration classes

Все @Configuration классы подклассы при запуске времени с CGLIB. В подклассе дочерний метод сначала проверяет контейнер для любых кешированных (облачных) бобов до того, как он вызывает родительский метод, а создает новый экземпляр.

Если проблема в вопросе сертификации является только один экземпляр new JdbcAccountRepository(), то да, то лучше использовать метод accountRepository()@Bean в @Configuration классе.