title: JSF backing bean structure (best practices)
body: <p>I hope that in this post, I can get people's opinions on best practices for the interface between JSF pages and backing beans.</p>
  
  <p>One thing that I never can settle on is the structure of my backing beans. Furthermore, I have never found a good article on the subject.</p>
  
  <p>What properties belong on which backing beans? When is it appropriate to add more properties to a given bean as opposed to creating a new bean and adding the properties onto it? For simple applications, does it make sense to just have a single backing bean for the whole page, considering the complexity involved with injecting one bean into another? Should the backing bean contain any actual business logic, or should it strictly contain data? </p>
  
  <p>Feel free to answer these questions and any others that may come up.</p>
  
  <hr />
  
  <p>As for reducing coupling between the JSF page and the backing bean, I never allow the JSF page to access any backing bean property's properties. For example, I never allow something such as:</p>
  
  <pre><code>&lt;h:outputText value="#{myBean.anObject.anObjectProperty}" /&gt;
  </code></pre>
  
  <p>I always require something like:</p>
  
  <pre><code>&lt;h:outputText value="#{myBean.theObjectProperty}" /&gt;
  </code></pre>
  
  <p>with a backing bean value of:</p>
  
  <pre><code>public String getTheObjectProperty()
  {
      return anObject.getAnObjectProperty();
  }
  </code></pre>
  
  <p>When I loop over a collection, I use a wrapper class to avoid drilling down into an object in a data table, for instance. </p>
  
  <p>In general, this approach feels "right" to me. It avoids any coupling between the view and the data. Please correct me if I'm wrong.</p>