Spring IoC: причины иметь нулевые проверки с автопроводкой конструктора

Question

Каковы причины использования нулевых проверок в пружинном автоподстановке?

Например, я часто вижу код, подобный следующему:

@Component
public class MyComponent {
    private final MyService myService;

    @Autowired
    public MyComponent(MyService myService) {
        Assert.notNull(myService, "myService must not be null");
        this.myService = myService;
    }
}

Какой смысл Assert.notNull() вызывать здесь?

Если я забуду объявить MyService как Bean Spring, произойдет сбой с:

NoSuchBeanDefinitionException: Нет доступного квалифицирующего компонента типа 'com.company.MyService': ожидается впо крайней мере 1 бин, который считается кандидатом на автопроводку.

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

Answer 1

Код бессмысленный.Spring выдаст исключение NoSuchBeanDefinitionException , если в контексте не найден потенциальный компонент.Это базовое поведение фреймворка, и я не вижу смысла его угадывать.

Вы можете указать, что aoutwired bean может быть необязательным:

@Autowired(required = false)

, но затем проверка на нольимеет еще меньше смысла.

Answer 2

Какой смысл здесь вызывать Assert.notNull ()?

В этом случае вы автоматически связываетесь с помощью конструктора, и цель утверждения - убедиться, что служба имеетбыло введено что-нибудь, кроме null правильно до , это вызывает какие-либо проблемы в будущем.Хотя NoSuchBeanDefinitionException генерируется, когда не определен ни один компонент правильного типа, null все еще может быть введен, и механизм автопроводки не справляется с этим, потому что это не его цель.