Use or not to use "Backing Bean" / "Manage Bean" with JSF?

2

On page 64 of the Algaworks e-book "Java EE 7 with JSF, PrimeFaces and CDI" explains the use of backing beans, which are , responsible for controlling the components of JSF pages.

But at the end of the explanation there is a paragraph that says:

  

"Although powerful, this feature should be used with great care.   can leave the source code large and difficult to understand. Most of the time, we can do what we need by using only value binding expressions. "

So my question is, why should I not use backing beans by default? I say I will build the application and I want to set a default, so the right is every page to have a backing bean , or just the more "complex" the rest I should treat in a < strong> manage-bean common.

    
asked by anonymous 13.07.2015 / 21:12

2 answers

0

It depends a lot on your application, I recommend using a @ManagedBean and defining a life cycle for your bean ( @ViewScoped , @RequestEscoped or @SessionScoped ), so you can already develop a quiet application. p>     

13.07.2015 / 22:11
0

Diego Santos ,

The ManagedBean would be its Controller of the application, our View .xhtml in case it gets access to our properties in ManagedBean or in our BB as in the example below:

Declaration of ManagedBean (As of version 2.0 we can do via Annotations before this only via .xml .

@ManagedBean(name = "comentario")
@ViewScoped <= Definição do escopo do ciclo de vida do seu ManagedBean
public class CComentario 
{
 private List<Anexo> listaAnexos; //Uma lista de Anexos

}

In your View we can perform validations such as:

  • Render components
  • Block access
  • Among others.

To perform a validation using the list available in the ManagedBean we can do as follows:

    <p:outputPanel rendered="#{fn:length(comentario.anexos) gt 0}">
       //aqui os elementos que serão renderizados
    </p:outputPanel>

We can also access attributes defined in your Backing bean

<strong> Comentário #{CComentario.comentario.descricao} </strong>

It is worth studying the life cycle of each scope we have available as:

@ApplicationScoped: It will be available all the time until the "hang" application

@SessionScoped: Is available while the session is valid.

@ViewScoped: It is only available on the page where it was declared.

@RequestScoped: Available between a single http call.

We also have:

@CustomScoped: Where you can create a custom scope.

@FlowScoped: You define the flow of life for example: Enter the window > choose product > purchase product > End . This available only in jsf 2.2 up

    
13.07.2015 / 22:44