Это вызвано природой отложенных выражений #{}(обратите внимание, что «устаревшие» стандартные выражения ${}ведут себя точно так же, когда Facelets используется вместо JSP). Отложенное выражение оценивается не сразу , а создается как ValueExpressionобъект, а метод get, стоящий за выражением, выполняется каждый раз при вызове кода ValueExpression#getValue().
Обычно он вызывается один или два раза за цикл запрос-ответ JSF, в зависимости от того, является ли компонент компонентом ввода или вывода ( подробнее об этом здесь ). Однако это число может возрасти (намного) выше, когда используется при итерации компонентов JSF (таких как <h:dataTable>и <ui:repeat>), или кое-где в логическом выражении, таком как renderedатрибут. JSF (в частности, EL) вообще не будет кэшировать вычисленный результат выражения EL, поскольку он может возвращать разные значения при каждом вызове (например, когда он зависит от текущей итерированной строки данных).
Оценка выражения EL и вызов метода-получателя - очень дешевая операция, поэтому вам вообще не следует об этом беспокоиться. Однако история меняется, когда вы по какой-то причине выполняете дорогостоящую DB / бизнес-логику в методе getter. Это будет повторяться каждый раз!
Методы получения в компонентах поддержки JSF должны быть спроектированы таким образом, чтобы они возвращали только уже подготовленное свойство и ничего более, в точности согласно спецификации Javabeans . Они вообще не должны делать дорогую БД / бизнес-логику. Для этого @PostConstructдолжны использоваться методы слушателя бина и / или (действия). Они выполняются только один раз в какой-то момент жизненного цикла JSF на основе запросов, и это именно то, что вам нужно.
Вот краткое изложение всех различных правильных способов предустановки / загрузки свойства.
public class Bean {
private SomeObject someProperty;
@PostConstruct
public void init() {
// In @PostConstruct (will be invoked immediately after construction and dependency/property injection).
someProperty = loadSomeProperty();
}
public void onload() {
// Or in GET action method (e.g. <f:viewAction action>).
someProperty = loadSomeProperty();
}
public void preRender(ComponentSystemEvent event) {
// Or in some SystemEvent method (e.g. <f:event type="preRenderView">).
someProperty = loadSomeProperty();
}
public void change(ValueChangeEvent event) {
// Or in some FacesEvent method (e.g. <h:inputXxx valueChangeListener>).
someProperty = loadSomeProperty();
}
public void ajaxListener(AjaxBehaviorEvent event) {
// Or in some BehaviorEvent method (e.g. <f:ajax listener>).
someProperty = loadSomeProperty();
}
public void actionListener(ActionEvent event) {
// Or in some ActionEvent method (e.g. <h:commandXxx actionListener>).
someProperty = loadSomeProperty();
}
public String submit() {
// Or in POST action method (e.g. <h:commandXxx action>).
someProperty = loadSomeProperty();
return "outcome";
}
public SomeObject getSomeProperty() {
// Just keep getter untouched. It isn't intented to do business logic!
return someProperty;
}
}
Обратите внимание, что вы не должны использовать конструктор bean-компонента или блок инициализации для задания, потому что он может вызываться несколько раз, если вы используете инфраструктуру управления bean-компонентом, использующую прокси, такие как CDI.
Если для вас действительно нет других способов из-за некоторых ограничивающих требований к дизайну, то вы должны ввести ленивую загрузку в метод getter. Т.е. если свойство есть null, то загрузить и присвоить его свойству, иначе вернуть его.
public SomeObject getSomeProperty() {
// If there are really no other ways, introduce lazy loading.
if (someProperty == null) {
someProperty = loadSomeProperty();
}
return someProperty;
}
Таким образом, дорогая БД / бизнес-логика не будет выполняться без необходимости при каждом вызове геттера.
Смотрите также:
