示例1：

Question

以下是2个实现相同目的的工作示例：检索应用程序全局的FAQ结果。我们根据输入值获取结果并更新数据表。

首先使用RequestScoped和bean bindng 第二个使用ApplicationScoped bean并查看绑定。

示例1：

XHTML

<h:inputText id="faqSearch" value="#{faqBean.filter}"/>
<h:commandButton value="submit" ajax="true" update="faqResults"/>

<h:dataTable
    id="faqResults"
    value="#{faqBean.retrieveResults()}"
    var="result">

        <h:column>${result}</h:column>

</h:dataTable>

豆

@RequestScoped
@ManagedBean
public class FaqBean {

   String filter;

   public String getFilter(){
       return filter;
   }

   public void setFilter(String filter){
       this.filter = filter;
   }

   public List<String> retrieveResults(){   
       //compute result from a backend service based on filter
       return doSomething(filter);
   }

示例2：

XHTML

<h:inputText id="faqSearch" binding="#{filter}"/>
<h:commandButton value="submit" ajax="true" update="faqResults"/>

<h:dataTable
    id="faqResults"
    value="#{faqBean.retrieveResults(filter.value)}"
    var="result">

        <h:column>${result}</h:column>

</h:dataTable>

豆

@ApplicationScoped
@ManagedBean
public class FaqBean {
   public List<String> retriveResults(String filter){   
       //Compute result from a backend service based on filter
       return doSomething(filter);
   }

所以1似乎是使用jsf的好方法。
但是2对我来说似乎是一个更好的解决方案，因为它不会在每次执行时创建/销毁bean，bean对应用程序是静态的。

但是通过这种思维方式我们可以摆脱所有请求的bean，所以它感觉不对。也许这个解决方案比第一个解决方案更糟糕，我不知道如何管理这一切。

那么最好的方法是什么？

Answer 1

这是一个意见问题，而不是分析服务器为每个请求创建新bean实例的成本。如果每个请求只检索1个单值，那么这些实现中的任何一个都是有效的，也许你应该使用后者，但是，因为它看起来不像你没有的真实用例执行任何业务逻辑并始终检索单个结果，但每个请求可以有不同的过滤器，然后第一个更好，因为你的getter必须尽可能干净。这意味着，在JSF托管bean中，getter 不应该具有任何业务逻辑，因为应用程序可以多次调用它们。因此，当您添加一些业务逻辑来处理过滤器时，您将意识到每个请求都可以返回不同的结果，这导致使用@RequestScoped bean的前一个实现。

由于您真正的问题是检索所有应用程序的全局FAQ信息，您应该将FAQ数据加载到应用程序的全局资源中，如缓存空间或另一个@ApplicationScoped bean，然后执行针对此全局资源的每个请求都不会命中您的数据库。

更多信息：

Why JSF calls getters multiple times

查看绑定＆amp; ApplicationScoped bean与RequestScoped bean

示例1：

示例2：

1 个答案: