Бобы Spring автоброска

Другой подход, который я также использую, - это автоматическое связывание класса начальной загрузки с использованием:

public class Main {
    @Autowired FooFacade foo;
    @Autowired BarFacade bar;

    public static void main(String[] args) {
        ApplicationContext ctx = new ClassPathXmlApplicationContext("appCtx.xml");
        AutowireCapableBeanFactory bf = ctx.getAutowireCapableBeanFactory();
        Object main = bf.createBean(Main.class, 
                                    AutowireCapableBeanFactory.AUTOWIRE_AUTODETECT,
                                    false);
        ((Main) main).run();
    }

    private void run() {
        foo.doBootstrapStuff();
        bar.doMoreBootstrapStuff();
    }
}

(Код сделан из памяти. Может работать, только если у вас настроен контекст Spring для обработки аннотаций проводки, в этом случае создание сеттеры для foo и bar должны работать.)

Основной причиной того, что getBean нетипизирован, является совместимость Spring (до версии 2.5.x) с Java 1.4. Spring 3.0 откажется от этого и, следовательно, предложит типизированный метод getBean .

Тем не менее, вам следует избегать прямого поиска bean-компонентов и минимизировать его использование, насколько это возможно.

. Ответ заключается в том, что вы вообще не должны использовать ApplicationContext.getBean (), если он ' Это возможно, и имейте в виду то место, которое вам нужно в коде начальной загрузки. (Как правило, вам никогда не нужно использовать getBean () вне точек входа вашего приложения.)

Кроме того, то, что вы спрашиваете, вероятно, вообще невозможно в языке Java. Приведение является функцией времени компиляции в сочетании с проверкой во время выполнения. Тип возврата getBean () просто должен быть известен во время компиляции. Даже если Spring может определить тип объекта, он не может изменять собственные сигнатуры методов во время выполнения.

Другое дело, что даже если бы это было возможно, эта функция не была бы такой полезной. Поскольку Spring AOP реализован с использованием динамических прокси, вы почти всегда хотите, чтобы Spring передавал вам экземпляр интерфейса, реализуемый компонентом (который может быть прокси AOP), а не класса реализации.

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

Кроме того, то, что вы спрашиваете, вероятно, вообще невозможно в языке Java. Приведение является функцией времени компиляции в сочетании с проверкой во время выполнения. Тип возврата getBean () просто должен быть известен во время компиляции. Даже если Spring может определить тип объекта, он не может изменять собственные сигнатуры методов во время выполнения.

Другое дело, что даже если бы это было возможно, эта функция не была бы такой полезной. Поскольку Spring AOP реализован с использованием динамических прокси, вы почти всегда хотите, чтобы Spring передавал вам экземпляр интерфейса, реализуемый компонентом (который может быть прокси AOP), а не класса реализации.

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

Кроме того, то, что вы спрашиваете, вероятно, вообще невозможно в языке Java. Приведение является функцией времени компиляции в сочетании с проверкой во время выполнения. Тип возврата getBean () просто должен быть известен во время компиляции. Даже если Spring может определить тип объекта, он не может изменять собственные сигнатуры методов во время выполнения.

Другое дело, что даже если бы это было возможно, эта функция не была бы такой полезной. Поскольку Spring AOP реализован с использованием динамических прокси, вы почти всегда хотите, чтобы Spring передавал вам экземпляр интерфейса, реализуемый компонентом (который может быть прокси AOP), а не класса реализации.

вам никогда не нужно использовать getBean () вне точек входа вашего приложения.)

Кроме того, то, что вы спрашиваете, вероятно, вообще невозможно на языке Java. Приведение является функцией времени компиляции в сочетании с проверкой во время выполнения. Тип возврата getBean () просто должен быть известен во время компиляции. Даже если Spring может определить тип объекта, он не может изменять собственные сигнатуры методов во время выполнения.

Другое дело, что даже если бы это было возможно, эта функция не была бы такой полезной. Поскольку Spring AOP реализован с использованием динамических прокси, вы почти всегда хотите, чтобы Spring передавал вам экземпляр интерфейса, реализуемый компонентом (который может быть прокси AOP), а не класса реализации.

вам никогда не нужно использовать getBean () вне точек входа вашего приложения.)

Кроме того, то, что вы спрашиваете, вероятно, вообще невозможно на языке Java. Приведение является функцией времени компиляции в сочетании с проверкой во время выполнения. Тип возврата getBean () просто должен быть известен во время компиляции. Даже если Spring может определить тип объекта, он не может изменять собственные сигнатуры методов во время выполнения.

Другое дело, что даже если бы это было возможно, эта функция не была бы такой полезной. Поскольку Spring AOP реализован с использованием динамических прокси, вы почти всегда хотите, чтобы Spring передавал вам экземпляр интерфейса, реализуемый компонентом (который может быть прокси AOP), а не класса реализации.

Переспросить, вероятно, вообще невозможно на языке Java. Приведение является функцией времени компиляции в сочетании с проверкой во время выполнения. Тип возврата getBean () просто должен быть известен во время компиляции. Даже если Spring может определить тип объекта, он не может изменять собственные сигнатуры методов во время выполнения.

Другое дело, что даже если бы это было возможно, эта функция не была бы такой полезной. Поскольку Spring AOP реализован с использованием динамических прокси, вы почти всегда хотите, чтобы Spring передавал вам экземпляр интерфейса, реализуемый компонентом (который может быть прокси AOP), а не класса реализации.

Переспросить, вероятно, вообще невозможно на языке Java. Приведение является функцией времени компиляции в сочетании с проверкой во время выполнения. Тип возврата getBean () просто должен быть известен во время компиляции. Даже если Spring может определить тип объекта, он не может изменять собственные сигнатуры методов во время выполнения.

Другое дело, что даже если бы это было возможно, эта функция не была бы такой полезной. Поскольку Spring AOP реализован с использованием динамических прокси, вы почти всегда хотите, чтобы Spring передавал вам экземпляр интерфейса, реализуемый компонентом (который может быть прокси AOP), а не класса реализации.

• изменить собственные сигнатуры методов во время выполнения.

Другое дело, что даже если бы это было возможно, эта функция не была бы такой полезной. Поскольку Spring AOP реализован с использованием динамических прокси, вы почти всегда хотите, чтобы Spring передавал вам экземпляр интерфейса, реализуемый компонентом (который может быть прокси AOP), а не класса реализации.

• изменить собственные сигнатуры методов во время выполнения.

Другое дело, что даже если бы это было возможно, эта функция не была бы такой полезной. Поскольку Spring AOP реализован с использованием динамических прокси, вы почти всегда хотите, чтобы Spring передавал вам экземпляр интерфейса, реализуемого компонентом (который может быть прокси AOP), а не класса реализации.

Что делать, если я использую Spring в качестве фабрики объектов, которую мое приложение широко использует. То есть, вместо того, чтобы писать кучу классов, которые уже наследуют или оборачивают известные классы Java, я просто решил переместить все это в файл xml, чтобы сократить строки кода Java. Это будет означать много строк xml, но мне не нужно делать скелетные классы Java, которые я ввожу с помощью Spring или autowire. Таким образом, линии кода Java меньше.

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

Я работал со Spring, но он все еще нов для меня, так что простите мой вопрос.

«Поскольку Spring AOP реализован с использованием динамических прокси, вы почти всегда хотите, чтобы Spring передавал вам экземпляр интерфейса, который реализует компонент (который может быть прокси AOP), а не класса реализации. "

Таким образом, невозможно получить динамический прокси-сервер с помощью getBean (), тогда что лучше всего, если нет интерфейсов и должен выполняться отдельный класс драйвера?