Конфигурируемый и Компонентный с Spring и AspectJ

Question

При использовании AspectJ, зачем использовать @Component вместо @ Configurable.

У меня есть Spring и AspectJ для поддержки @Transactional, аспектов самовывоза и внедрения в объекты JPA. Это прекрасно работает.

Я использую @Component для большинства классов, которым требуется внедрение, и, таким образом, либо включение их в свои зависимости. Или, когда я не могу, внедрить ApplicationContext и затем использовать getBean () в качестве последнего средства. И я резервирую @Configurable только для объектов JPA (Hibernate), которые нуждаются в инъекции. Я также начал использовать @Configurable для тестов jUnit, чтобы облегчить написание тестов. Это также прекрасно работает.

Но мне любопытно. Если AspectJ теперь автоматически вводит (beanifying) что-либо с аннотацией @Configurable, независимо от того, как она была построена; getBean (), new (), @Autowired. Почему бы мне просто не перейти на использование @Configurable для всех моих компонентов? Затем я могу полностью отказаться от контекста приложения и getBean (), а просто от новых () классов, которые я не могу внедрить.

Я понимаю, что не упомянул о конфигурации XML-бина. Я не уклоняюсь от этого, но этот проект не требует ничего. Я просто конструктор или сеттер вводить зависимости при тестировании. очень просто.

Answer 1

@ Компонент - это интерфейс маркера Spring, который может дать подсказки Spring, когда дело доходит до автоматического обнаружения bean-компонентов.

@ Configurable - это маркер, используемый в AOP-ткачестве, загружаемом во время загрузки.

Эти двое не имеют ничего общего друг с другом.

Answer 2

@Component для классов, которые будут созданы самой Spring, в то время как @Configurable для классов, которые будут созданы вашим собственным кодом или другим фреймворком - например, сущностями Hibernate или Servlets контейнером сервлета .

Answer 3

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

Для @Component он вам вообще не нужен, потому что обычно все экземпляры управляются Spring.