Spring lookup-метод и использование прокси

Question

Я немного озадачен использованием метода инъекции (lookup-method) и aop scoped-proxy (поскольку оба используются для инъекции различных bean-объектов), поэтому

1) Когда использовать метод инъекции, а когда использовать прокси-сервер с разрешением aop? 2) Какова причина, по которой прокси-сервер с ограниченным доступом не будет использоваться для бина-прототипа?

Answer 1

На вопрос 1. Когда использовать метод инъекции, а когда использовать прокси с апоп-областью?

Допустим, у вас есть одноэлементный компонент A, зависящий от прототипа компонента B. В A есть метод m, в который вовлечен B.

Вы получили объект a из A и выполните метод m несколько раз. Каждый раз, когда m выполняется, новый объект b из B должен вводиться в a. Это время, когда вы используете метод инъекции.

Кроме того, если у вас есть одноэлементный компонент A, он зависит от сессионного компонента B. В A есть метод m, в котором задействован B.

Вы получили объект a из A и выполните метод m несколько раз. Пока время выполнения находится в одном сеансе, a имеет один и тот же объект b из B. Это время, когда вы используете прокси.

Answer 2

Инжекция с использованием метода поиска и прокси с областью действия - это средство для внедрения бобов с более коротким сроком жизни в бины с большим сроком службы. Однако они обслуживают разные варианты использования.

Внедрение метода полезно в тех случаях, когда бин-одиночка имеет зависимость от бина-прототипа.

Прокси-сервер вводится вместо желаемого компонента и предоставляет этот компонент в зависимости от контекста. Например, если одноэлементный бин (например, контроллер Spring MVC) автоматически подключает бин с заданной областью сеанса, то прокси-сервер доставляет этот бин, принадлежащий текущему сеансу HTTP.

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

Однако внедрение метода имеет ограничения, поскольку оно основано на абстрактных методах. Следовательно, некоторые вещи, такие как написание модульных тестов, более обременительны, так как вам нужно обеспечить реализацию-заглушку абстрактного метода. Сканирование компонентов также не работает с абстрактными классами.

Одной альтернативой внедрению метода является ObjectFactory Spring или его эквивалент JSR Provider .

Другой простой способ создания экземпляров прототипа bean-компонента во время выполнения (который даже позволяет предоставлять аргументы конструктора) - реализовать фабрику bean-компонентов, как показано ниже:

@Configuration
public class MyProvider {

    @Bean
    @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
    public MyThing create(String name) {
        return new MyThing(name);
    }

}

Использование:

@Component
public class MySingleton {

    @Autowired
    private MyProvider myProvider;

    public void doStuffThatNeedsAPrototypeBeanInstance() {
        MyThing thing = myProvider.create("some name");
        ...
    }
}