Olá André!

Quais são as características de um livro? São várias como o ISBN, editora, autor, etc. Sabemos que é papel do ManagedBean fornecer os dados para view. Nesse caso, o managedBean teria atributos como ISBN, editora, autor.

Agora, eu te pergunto: olhando para o managedBean.. ele é UM livro? Não, ele apenas guarda os dados que capturamos do formulário. Aliás, ele poderia ter outros atributos não relacionados com livro, afinal, ele é apenas um palco para capturar e disponibilizar dados para view (nossa página).

Puxa vida, então, onde está o Livro no meu sistema? Para que o Livro apareça, criaremos uma classe chamada Livro e nela colocaremos todos os dados do livro que antes estavam no ManagedBean. Agora, no lugar do ManagedBean ter vários atributos ele terá apenas um atributo que será uma instância da classe Livro.

Se mais tarde você quiser deixar de usar JSF e optar pelo VRaptor ou Spring você conseguirá aproveitar o modelo Livro, porque ele agora é independente do ManagedBean que é uma tecnologia específica do JSF.

Se você tivesse mantido os dados do livro apenas no ManagedBean, perderia essas informações quando deixasse de usar JSF. Está reparando que a classe Livro será reutilizada independente do framework web escolhido? É por esta razão que o autor do exercício decidiu separar de um lado o Livro e de outro o LivroBean.

Mas não se esqueça: em JSF, para que seja possível acessar os atributos de LivroBean na view precisamos de getters/setters. É por isso que LivroBean além do atributo private Livro livro = new Livro() possui o método public Livro getLivro(). É isso que possibilita seu acesso via expression language #{livroBean.livro.titulo}.

Espero ter ajudado.

Perfeito Flávio, ficou mais do que claro pra mim!!

Apenas uma última dúvida,

"Aliás, ele poderia ter outros atributos não relacionados com livro, afinal, ele é apenas um palco para capturar e disponibilizar dados para view (nossa página)."

Neste caso, se eu quiser criar um ManagedBean genérico onde eu recebo todos os dados da classe anúncio e anunciante eu tenho essa possibilidade?

Se sim, isso pode ser considerado correto também ou temos o motivo da padronização de um ManagedBean por classe(no caso de ser uma boa prática)?

Exemplo de uma chamada de expression language deste caso:

{GenericBean.anunciante.nome}

{GenericBean.anuncio.modelo}

Muito obrigado pelos esclarecimentos e pela atenção. Parabéns pelo seu profissionalismo.

Olá! André, fico contente em ter esclarecido a sua dúvida, obrigado. Agora vamos a sua segunda pergunta:

Normalmente, um ManagedBean do JSF está ligado a uma View (aliás, uma view pode referenciar através de expression language outros ManagedBeans). Em JSF view é sinônimo de página. Vejamos o LivroBean com informações que não dizem respeito ao livro, um exemplo:

@ManagedBean
public class LivroBean {
  private Livro livro = new Livro();
  private boolean exibido = false;
  // getters e setters
}

O que é o atributo exibido? Com certeza não é algo do livro. Ele é usado para controlamos algum componente visual do JSF. Por exemplo, na view livro.xhml(lembre-se que view é sinônimo de página) poderíamos ter:

<!-- em livro.xhtml -->
<h:outputLabel value="Livro em promoção" render="#{livroBean.exibido}"/>

Neste caso, como usamos o atributo render, o componente só será exibido se o valor de livroBean.exibido é true. Ai, voltamos para a primeira resposta. O atributo exibido de LivroBean é alguma informação do Livro? Com certeza não. Ele só está lá para que você possa controlar como sua view será exibida.

Agora, vamos voltar à sua pergunta sobre o GenericBean. Primeiro, você está de parabéns por ter a preocupação de não repetir código, aplicando o princípio DRY (don't repeat your self), porém, no contexto de um ManagedBean, não faz muito sentido um ManagedBean genérico. Mas qual a razão disso?

Um ManagedBean, como lhe mostrei, tem como papel expor seu model para a view, em nosso caso, Livro, porém ele também contém atributos que estão atrelados à sua view. Por exemplo, guardar um valor para saber se um botão foi pressionado, um para exibir ou esconder algo. Sendo assim, um ManagedBean está muito atrelado à view a qual ele está fornecendo dados e não faz muito sentido criar um ManageBean genérico. O que seria genérico se cada página é muito diferente uma das outras?

Mas Flávio, que tal se eu criasse um único ManagedBean que fosse utilizado para todas as páginas, tipo um GenericBean. O problema dessa abordagem é que você teria que colocar os dados do livro, autor, papaguaio, calopsita e vários métodos que não possuem relação entre si. Daí, seu GenericBean ficaria gigante e a manutenção problemática, ferindo assim o princípio de responsabilidade única (SRP -> Single Responsability Principle).

Então, você pode criar um ManagedBean por classe (Autor, Livro) que você deseja expor em sua view, ou não. Tudo depende. Você pode ter um ConfiguracaoBean que faz um monte de coisa no seu sistema, mas não existe a classe Configuração.

É isso. Espero ter esclarecido ainda melhor sua dúvida.

Abraço

Hum, bolei um resumo de tudo que falei: veja o ManagedBean como uma passarela (gateway) para que você possa expor seu Livro, Autor, Recibo, isto é, para que você possa expor os modelos do domínio para a view. Utilizar no mesmo ManagedBean a classe A ou B vai depender de como você quer organizar sua página (view). É bem comum termos um ManagedBean para cada classe do modelo de domínio, pode ficar tranquilo, mas nem sempre é assim.

Flavio, Muito obrigado pelas explicações. Hoje você me fez gostar mais de estar aprendendo Java na Alura. Parabéns mais uma vez pelo profissionalismo. Professores como você são pessoas que motivam o interesse no aprendizado. Até a próxima.

Abraço!