Qual seria a melhor prática para a confecção de um caso de uso (por exemplo: manterUsuarios)?
Apenas um único bean para toda a funcionalidade do caso de uso, como por exemplo:
------> listarUsuarios
------> incluirUsuario
------> alterarUsuario
Ou um bean para cada caso de uso (no caso acima seriam três beans).
No primeiro exemplo (é o que eu estou fazendo e o que mais tenho visto), temos apenas um único bean com essas funcionalidades, porém o código se estende a centenas de linhas… o que não me parece uma boa 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
}
}
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?
[quote=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.[/quote]
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!!
[quote=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?
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:
A senha é válida?
Qual é o perfil, afinal?
Falta quanto tempo para a senha expirar?
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?
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.
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 é?