Почему JSF вызывает геттеры несколько раз
Допустим, я указываю компонент outputText следующим образом:
<h:outputText value="#{ManagedBean.someProperty}"/>
Если я печатаю сообщение журнала, когда получатель для someProperty вызывается и загружает страницу, тривиально заметить, что геттер вызывается более одного раза за запрос (два или три раза это то, что произошло в моем случае):
DEBUG 2010-01-18 23:31:40,104 (ManagedBean.java:13) - Getting some property
DEBUG 2010-01-18 23:31:40,104 (ManagedBean.java:13) - Getting some property
Если значение someProperty дорого рассчитать, это может быть проблемой.
Я немного погуглил и понял, что это известная проблема. Одним из обходных путей было включить проверку и посмотреть, был ли он уже рассчитан:
private String someProperty;
public String getSomeProperty() {
if (this.someProperty == null) {
this.someProperty = this.calculatePropertyValue();
}
return this.someProperty;
}
Основная проблема заключается в том, что вы получаете множество шаблонного кода, не говоря уже о частных переменных, которые вам могут не понадобиться.
Каковы альтернативы этому подходу? Есть ли способ достичь этого без такого большого количества ненужного кода? Есть ли способ остановить поведение JSF таким образом?
Спасибо за ваш вклад!
8 ответов
Это вызвано характером отложенных выражений #{} (обратите внимание, что "устаревшие" стандартные выражения ${} ведут себя точно так же, когда Facelets используется вместо JSP). Отложенное выражение оценивается не сразу, а создается как ValueExpression объект и метод получения за выражением выполняется каждый раз, когда код вызывает ValueExpression#getValue(),
Обычно это вызывается один или два раза за цикл JSF-запрос-ответ, в зависимости от того, является ли компонент компонентом ввода или вывода ( узнайте это здесь). Однако это число может увеличиться (намного) выше при использовании в итерации компонентов JSF (таких как <h:dataTable> а также <ui:repeat>), или здесь и там в логическом выражении типа rendered приписывать. JSF (в частности, EL) вообще не будет кэшировать вычисленный результат выражения EL, поскольку он может возвращать разные значения при каждом вызове (например, когда он зависит от текущей итерированной строки данных).
Оценка выражения EL и вызов метода get - это очень дешевая операция, поэтому вам вообще не следует об этом беспокоиться. Однако история меняется, когда вы по какой-то причине выполняете дорогостоящую DB/ бизнес-логику в методе getter. Это будет повторяться каждый раз!
Методы получения в компонентах поддержки JSF должны быть спроектированы таким образом, чтобы они возвращали только уже подготовленное свойство и ничего более, в соответствии со спецификацией Javabeans. Они вообще не должны делать дорогую БД / бизнес-логику. Для этого бобов @PostConstruct и / или (action) методы слушателя должны быть использованы. Они выполняются только один раз в какой-то момент жизненного цикла 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;
}
Таким образом, дорогая БД / бизнес-логика не будет выполняться без необходимости при каждом вызове геттера.
Смотрите также:
- Почему метод get так часто вызывается атрибутом рендеринга?
- Вызвать JSF-управляемое действие bean-компонента при загрузке страницы
- Как и когда я должен загрузить модель из базы данных для h:dataTable
- Как заполнить опции h:selectOneMenu из базы данных?
- Отображение динамического изображения из базы данных с помощью p:graphicImage и StreamedContent
- Определение и повторное использование переменной EL на странице JSF
С JSF 2.0 вы можете подключить слушателя к системному событию
<h:outputText value="#{ManagedBean.someProperty}">
<f:event type="preRenderView" listener="#{ManagedBean.loadSomeProperty}" />
</h:outputText>
В качестве альтернативы вы можете заключить страницу JSF в f:view тег
<f:view>
<f:event type="preRenderView" listener="#{ManagedBean.loadSomeProperty}" />
.. jsf page here...
<f:view>
Я написал статью о том, как кэшировать средство получения JSF-компонентов с помощью Spring AOP.
Я создаю простой MethodInterceptor который перехватывает все методы, отмеченные специальной аннотацией:
public class CacheAdvice implements MethodInterceptor {
private static Logger logger = LoggerFactory.getLogger(CacheAdvice.class);
@Autowired
private CacheService cacheService;
@Override
public Object invoke(MethodInvocation methodInvocation) throws Throwable {
String key = methodInvocation.getThis() + methodInvocation.getMethod().getName();
String thread = Thread.currentThread().getName();
Object cachedValue = cacheService.getData(thread , key);
if (cachedValue == null){
cachedValue = methodInvocation.proceed();
cacheService.cacheData(thread , key , cachedValue);
logger.debug("Cache miss " + thread + " " + key);
}
else{
logger.debug("Cached hit " + thread + " " + key);
}
return cachedValue;
}
public CacheService getCacheService() {
return cacheService;
}
public void setCacheService(CacheService cacheService) {
this.cacheService = cacheService;
}
}
Этот перехватчик используется в файле конфигурации Spring:
<bean id="advisor" class="org.springframework.aop.support.DefaultPointcutAdvisor">
<property name="pointcut">
<bean class="org.springframework.aop.support.annotation.AnnotationMatchingPointcut">
<constructor-arg index="0" name="classAnnotationType" type="java.lang.Class">
<null/>
</constructor-arg>
<constructor-arg index="1" value="com._4dconcept.docAdvance.jsfCache.annotation.Cacheable" name="methodAnnotationType" type="java.lang.Class"/>
</bean>
</property>
<property name="advice">
<bean class="com._4dconcept.docAdvance.jsfCache.CacheAdvice"/>
</property>
</bean>
Надеюсь, это поможет!
Первоначально опубликовано на форуме PrimeFaces @ http://forum.primefaces.org/viewtopic.php?f=3&t=29546
Недавно я был одержим оценкой производительности моего приложения, настройкой JPA-запросов, заменой динамических SQL-запросов именованными запросами, и только сегодня утром я понял, что метод getter был скорее ГОРЯЧИМ SPOT в Java Visual VM, чем остальные. мой код (или большая часть моего кода).
Метод получения:
PageNavigationController.getGmapsAutoComplete()
Ссылка на пользовательский интерфейс: включить в index.xhtml
Ниже вы увидите, что PageNavigationController.getGmapsAutoComplete () является горячей точкой (проблемой производительности) в Java Visual VM. Если вы посмотрите дальше вниз, на снимке экрана вы увидите, что getLazyModel (), метод получения ленивых данных в PrimeFaces, также является горячей точкой, только когда конечный пользователь выполняет много "ленивых данных" типа вещей / операций / задач в приложении.:)
Смотрите (оригинальный) код ниже.
public Boolean getGmapsAutoComplete() {
switch (page) {
case "/orders/pf_Add.xhtml":
case "/orders/pf_Edit.xhtml":
case "/orders/pf_EditDriverVehicles.xhtml":
gmapsAutoComplete = true;
break;
default:
gmapsAutoComplete = false;
break;
}
return gmapsAutoComplete;
}
На что ссылается следующее в index.xhtml:
<h:head>
<ui:include src="#{pageNavigationController.gmapsAutoComplete ? '/head_gmapsAutoComplete.xhtml' : (pageNavigationController.gmaps ? '/head_gmaps.xhtml' : '/head_default.xhtml')}"/>
</h:head>
Решение: поскольку это метод "getter", перед вызовом метода переместите код и присвойте значение gmapsAutoComplete; см. код ниже.
/*
* 2013-04-06 moved switch {...} to updateGmapsAutoComplete()
* because performance = 115ms (hot spot) while
* navigating through web app
*/
public Boolean getGmapsAutoComplete() {
return gmapsAutoComplete;
}
/*
* ALWAYS call this method after "page = ..."
*/
private void updateGmapsAutoComplete() {
switch (page) {
case "/orders/pf_Add.xhtml":
case "/orders/pf_Edit.xhtml":
case "/orders/pf_EditDriverVehicles.xhtml":
gmapsAutoComplete = true;
break;
default:
gmapsAutoComplete = false;
break;
}
}
Результаты теста: PageNavigationController.getGmapsAutoComplete () больше не является HOT SPOT в Java Visual VM (даже больше не отображается)
Разделяя эту тему, поскольку многие опытные пользователи посоветовали начинающим разработчикам JSF НЕ добавлять код в методы getter.:)
Если вы используете CDI, вы можете использовать методы Producers. Он будет вызываться много раз, но результат первого вызова кэшируется в области действия компонента и эффективен для получателей, которые вычисляют или инициализируют тяжелые объекты! Смотрите здесь, для получения дополнительной информации.
Возможно, вы могли бы использовать AOP для создания какого-либо аспекта, который кэшировал результаты наших получателей в течение настраиваемого промежутка времени. Это избавит вас от необходимости копировать и вставлять шаблонный код в десятки методов доступа.
Я бы также посоветовал использовать такой Framework, как Primefaces, вместо стандартного JSF, они решают такие проблемы до того, как команда JSF e. g в Primefaces вы можете установить частичную отправку. В остальном BalusC хорошо это объяснил.
Если значение someProperty слишком дорого для вычисления, это может стать проблемой.
Это то, что мы называем преждевременной оптимизацией. В редких случаях, когда профилировщик говорит вам, что вычисление свойства настолько дорого обходится, что вызов его трижды, а не один раз оказывает значительное влияние на производительность, вы добавляете кеширование, как вы описываете. Но если вы не делаете что-то действительно глупое, например, деление простых чисел или доступ к базе данных в геттере, ваш код, скорее всего, будет иметь десяток худших неэффективностей в тех местах, о которых вы никогда не задумывались.
Это все еще большая проблема в JSF. Например, если у вас есть метод isPermittedToBlaBla для проверки безопасности и на ваш взгляд, у вас есть rendered="#{bean.isPermittedToBlaBla} тогда метод будет вызываться несколько раз.
Проверка безопасности может быть сложной, например. LDAP-запрос и т. Д. Поэтому вы должны избегать этого с
Boolean isAllowed = null ... if(isAllowed==null){...} return isAllowed?
и вы должны обеспечить в сессионном компоненте это для каждого запроса.
Я думаю, что JSF должен реализовать здесь некоторые расширения, чтобы избежать нескольких вызовов (например, аннотации @Phase(RENDER_RESPONSE) Вызовите этот метод только один раз после RENDER_RESPONSE фаза...)