JSF: Dúvida sobre qual a melhor prática

olha só… poderia ser um único bean, pois agregaria as funcionalidades específicas do usuário por exemplo…

porém vc deve usar o MVC, e toda sua lógica de de inclui, listar, atualizar devem estar num DAO por exemplo…o que iria desacoplar bastante seu código…

por exemplo, tenho um bean que tenho estas funcionalidades, da minha view eu ligo direto nas propriedades do usuario, por exemplo o campo nome fica value="#{usuario.nome}" e um botão salvar ficaria action="#{bean.salvaUsuario}"e basicamente minha classe nessa parte é assim:

public class Bean{
    private Usuario usuario; 
    // get e set pra usuário

   public String salvaUsuario{
        usuarioFacade.salvarUsuario(this.usuario); // chamo minha facade que posteriomente chama minha DAO pra salvar o objeto usuario
      return null; // pra ficar na mesma página e se tudo ok, mostra mensagem de usuario cadastrado
 
  }
}

flw Hewerton

Claro,
mas é isto mesmo que a gente faz: um único bean!
Porém, por ser um único bean contendo todas as funcionalidades, ele tende a ficar muito grande (muitas linhas de código), o que pode dificultar a manutenção.
Então eu poderia perguntar: Alguém utiliza um bean para cada funcionalidade de um mesmo caso de uso? Isto é má prática?

Obrigado.

Um bkb para cada caso de uso é o mais correto. Ajuda muito na manutençao

Uma classe para salvar, outra para alterar e outra para apagar … não são classes … são estruturas de dados e ainda por cima mal modeladas.

Pra que usar uma linguagem orientada a objetos se você não trabalha com objetos?

Na verdade ele tem que criar métodos que façam essas operaçoes, e nao várias classes!

knik:

Claro,
mas é isto mesmo que a gente faz: um único bean!
Porém, por ser um único bean contendo todas as funcionalidades, ele tende a ficar muito grande (muitas linhas de código), o que pode dificultar a manutenção.
Então eu poderia perguntar: Alguém utiliza um bean para cada funcionalidade de um mesmo caso de uso? Isto é má prática?

Obrigado.

tende a ficar grande se vc não souber usar no mínimo um padrão MVC para saber como lidar com as coisas!

imagina se eu tiver 150 classes e cada uma eu tiver 10 métodos, pela sua idéia eu criaria 1500 classes :?: :!: :!: :!: :shock:

tá louco meu, aprenda certinho a OO e já terá uma visão muito melhor!!

Lezinho:

Uma classe para salvar, outra para alterar e outra para apagar … não são classes … são estruturas de dados e ainda por cima mal modeladas.

Pra que usar uma linguagem orientada a objetos se você não trabalha com objetos?

hehehehe tmb acho, boa pergunta pra ele!

Não Não Não …

Calma aí…

A minha fachada expõe todos os métodos de que preciso para me comunicar com a camada de persistência.
Então, eu (o bean) simplesmente dou uma ordem assim:

“Fachada!!! recupere um usuário (do banco de dados) para mim baseado no objeto usuário que estou te mandando como parâmetro!”

Então a minha fachada, se encontrar o “tal” usuário, irá me devolver ele, com todos os seus atributos.

Agora eu (o bean) tendo o objeto usuário nas mãos, vou fazer vários testes com ele para saber se ele é válido ou não, tais como:

1. A senha é válida?
2. Qual é o perfil, afinal?
3. Falta quanto tempo para a senha expirar?
4. Este usuário está bloqueado?

Bem, tudo isto é prá lá de ORIENTAÇÃO A OBJETOS, nem cogito isto.

Mas fica uma só dúvida: Fazer tudo isto gasta muitas linhas de código. É correto fazer isto dentro do bean, possuindo o objeto em mãos e realizando vários testes com ele? ou o melhor seria realizar todos esses testes dentro da FACHADA?

Falows?..

ÊPA! TAlvez eu não tenha sido bem claro…

O objeto usuario passado como parâmetro possui os atributos nome (ou login) e senha, provenientes de uma página, digamos, login.jspx (mas tudo bem, poderia mandar apenas um “Id”). Este objeto usuario é injetado via Spring, cujos mapeamentos OR-JPA apontam para uma tabela no meu PostgreSQL chamada usuario.

A minha fachada de login possui apenas um método, chamado “recuperarUsuario”, que recebe o parâmetro usuario proveniente do bean.

Esta fachada (que é um controlador, evidentemente), acionará o meu DAO na tentativa de recuperar este registro no banco de dados, que será “encapsulado” no objeto usuario (na minha classe de domínio Usuario - falando a grosso modo).

Se o usuário for recuperado convenientemente, daí seriam realizados os testes mencionados na mensagem anterior.

Mas fica aquela dúvida, já postada anteriormente.

Sacaram?

Eu entendi, tenho todas essas verificações para o Usuário na minha app e o método responsável por isso, o “logon”, é bem enxuto…na minha concepção, nem vejo a necessidade de um objeto Facade se a sua aplicação não for distribuída (se ela tende a ser, aí é outro papo), não é?

Abraço

Centenas de linhas?

Tenho uma com mais de 1000.

Sei que tem muita coisa errada, mas na pressa começa a sair isso memos :P, vou entregar o projeto logo depois faço um Refactoring em tudo.

Tá certo…

O negócio é entregar o projeto (mostrar serviço) e FATURAR. Depois faz um refactoring e …

Bom, mas depois você vai ficar com complexo de culpa, isto se o teu gerente não descobrir…

Legal pessoal, acho que o caminho já foi traçado: o bean tem mesmo de fazer estes testes.

Abraço a todos.

ahuUIAHuiahUIAHuiahIUHAuhaiUH

tb acho.