На мой взгляд, scoped managedBean, мне нужно заполнить список данными из БД. Я делаю это через прямой вызов от конструктора, что-то вроде этого:
public MyClass(){
list=populateFromDb();
}
но этот метод можно вызвать в аннотированном методе @PostConstruct, например:
public MyClass(){
}
@PostConstruct
populateFromDb(){...}
В чем разница между этим?
Если bean имеет область запроса, @PostConstruct будет выполняться каждый раз. Он будет вызываться после создания управляемого bean, но до bean помещается в область видимости. Такой метод не принимает аргументов, возвращает void и не может объявлять исключенное исключенное исключение. Метод может быть общедоступным, защищенным, приватным или закрытым пакетом. Если метод выдает исключение, исключение, реализация JSF не должна помещать управляемый bean в сервисы, и никакие дальнейшие ментоды в этом управляемом экземпляре bean не будут вызваны.
public TrainingClassForm() {
}
@PostConstruct
public void init() {
if (this.trainingListModel.getListDataModel() != null) {
this.trainingListModel.getAllTrainingClasses();
}
}
Отсылаем вам этот вопрос о стеке
В управляемом bean, @PostConstruct вызывается после обычного конструктора объектов Java. < Когда конструктор вызывается, bean еще не инициализирован, т.е. никакие зависимости не вводятся. В методе @PostConstruct bean полностью инициализирован, и вы можете использовать зависимости @PostConstruct - это контракт, который гарантирует, что этот метод будет вызываться только один раз в bean жизненном цикле. Может случиться (хотя и маловероятно), что bean создается несколько раз контейнером во внутренней работе, но гарантирует, что @PostConstruct будет вызываться только один раз.
Если ваш класс выполняет всю свою инициализацию в конструкторе, то @PostConstruct действительно является избыточным.
Однако, если ваш класс имеет свои зависимости, введенные с использованием методов setter, конструктор класса не может полностью инициализировать объект, а иногда некоторая инициализация должна выполняться после того, как все методы setter были вызваны, следовательно, используется прецедент @PostConstruct
Также см. Это и this