JSF - jaka jest różnica między @PostConstruct i bezpośrednim wywołaniem metody od konstruktora?

Question

W moim widoku zasięgiem managedBean, muszę wypełnić listę danych z DB. Im robi to poprzez bezpośrednie rozmowy z konstruktora, coś takiego:

public MyClass(){ 
    list=populateFromDb(); 
} 

ale metoda ta może być wywołana w @PostConstruct odnotowany metody, jak:

public MyClass(){ 
} 

@PostConstruct 
populateFromDb(){...} 

jaka jest różnica między to?

Answer 1

Jeśli komponent bean ma zasięg żądania, @PostConstruct zostanie wykonany za każdym razem. Zostanie wywołana po utworzeniu komponentu bean zarządzanego, ale zanim komponent bean zostanie umieszczony w zasięgu. Taka metoda nie przyjmuje argumentów, zwraca nieważność i nie może zadeklarować sprawdzonego wyjątku, który ma zostać zgłoszony. Metoda może być publiczna, chroniona, prywatna lub pakietowa. Jeśli metoda zgłasza niezaznaczony wyjątek, implementacja JSF nie może włączyć zarządzanego komponentu bean i nie będzie wywoływana żadna kolejna menthoda dla tej zarządzanej instancji komponentu bean.

public TrainingClassForm() { 

    } 
    @PostConstruct 
    public void init() { 
     if (this.trainingListModel.getListDataModel() != null) { 
      this.trainingListModel.getAllTrainingClasses(); 
     } 

    } 

nawiązujący do this question of stack
W zarządzanym fasoli, @PostConstruct nazywa po regularnym konstruktora obiektu Java.
po wywołaniu konstruktora komponent bean nie został jeszcze zainicjowany - tzn. Nie są wstrzykiwane żadne zależności. W metodzie @PostConstruct fasoli jest w pełni zainicjowany i można użyć zależności

@PostConstruct jest kontrakt, który gwarantuje, że ta metoda zostanie wywołana tylko raz w cyklu fasoli. Może się zdarzyć (choć jest mało prawdopodobne), że komponent bean w instancji wewnętrznej jest tworzony wielokrotnie, ale gwarantuje, że zostanie wywołany tylko jeden raz.
Jeśli klasa wykonuje całą swoją inicjalizację w konstruktorze, wówczas @PostConstruct jest rzeczywiście nadmiarowy.
Jednakże, jeśli klasa ma swoje zależności wstrzykiwany przy metod ustawiających, a następnie konstruktor klasy mogą nie w pełni zainicjować obiekt, a czasami potrzebuje trochę inicjalizacji należy wykonać po wszystkie metody setter zostały nazwane, stąd przypadek zastosowania @PostConstruct
Również see this i this