Olá,
Este tópico pode ficar bastante interessante então vou postar minha visão também =)
Começando do começo, o JSF é uma “implementação” do padrão Model 2, que na verdade é o padrão MVC adicionado do padrão Front Controller.
A View do JSF é praticamente composta por páginas JSF. Aqui é fácil.
Já o controle é um pouco mais difícil de entender visto que o JSF implementa parte dele para nós. A idéia do Model 2 é justamente prover um controle central, representado pelo Servlet do Faces.
O JSF não conhece sua aplicação, portanto, não poderia realizar todos os mapeamentos de eventos de tela em ações do modelo certo? Então esta parte do controle nós precisamos implementar. Daí entra os chamados Backing Beans, são eles que possuem os métodos que serão disparados pelo JSF quando determinado evento ocorrer. Estas classes também fazem parte do controle.
Agora, vamos para o modelo. A discussão aqui (nesta camada) pode ser extensa. A primeira abordagem é utilizar sempre POJO´s, ou seja, temos objetos fantoches que são “burros”, só possuem os atributos e os getters e setters. Não estou dizendo que isso é ruim, é apenas uma abordagem.
Se vc considerar que seus POJO´s não possuem nada além de getters e setters, alguém terá que realizar operações sobre essas classes para implementar as regras de negócio do sistema. Algumas pessoas optam por deixar o Backing Bean fazer este tipo de coisa, ou seja, o seu método verficarLogin() ficaria no BackingBean. Não minha opinião isto não é o ideal visto que Backing Bean faz parte do controle e não do modelo, o que também acarreta problemas de reaproveitamento de código.
Uma outra abordagem é criar uma camada de serviço (Service Layer), que é um padrão de projeto empregado com certo sucesso recentemente. A idéia aqui é deixar que esta camada, que faz parte do modelo, realize operações sobre os POJO´s. Dessa forma, nossos backing beans apenas mapeiam eventos de tela para chamadas de “serviços” nesta camada. Aqui, teríamos um método no Backing Bean, actionVerificarLogin() por exemplo, que invocaria o método verificarLogin() da camanda de serviço.
Outra abordagem que conheço é tornar seus POJO´s mais inteligentes e deixar lógica de negócio neles. Neste caso, o método verificarLogin() ficaria na classe Usuário.
Cada caso é um caso. Eu atualmente utilizo a abordagem da Service Layer pois ela tem outros benefícios que eu preciso. No entanto, em outros projetos estou inclinado a utilizar objetos mais inteligentes e empregar a OO de forma mais “pura”.
Para mais referências sobre esses assuntos eu sugiro a leitura dos livros Java Server Faces in Action de Kito D. Mann e do Patterns of Enterprise Application Architecture do Martin Fowler.
Desculpem o tamanho do comentário mas como eu disse, o assunto é interessante principalmente para quem está começando.
