1-No tutorial ele cria a classe BO que tem os métodos de negócio que acessam a DAO. É certo isso ? O melhor padrão é o BO para implementar essa funcionalidade ?
2-Uma outra dúvia é relação ao objeto que terão os atributos do meu formulário.
Por exemplo:
Se eu tiver fazendo um cadastro de usuário, é melhor eu criar um classe Usuario com seus atributos e colocá-la dentro do manageBean ou colocar os atributos como variáveis de instância do manageBean ?
Quando comecei com Spring e Hibernate eu li esse tutorial que me permitiu compreender de maneira mais clara essa estrutura.
Bom, entendo que sim, utilizar um BO é uma pratica bastante coerente, pela estrutura que é definida no exemplo.
Vale ressaltar que o modelo do projeto delimita a estrutura que será utilizada.
Com relação à segunda pergunta, você não percebe muito a diferença quando trabalha com 1 ou 2 objetos diferentes em um managedbean (como carro e garagem, por exemplo).
Agora, quando você possui um número maior de objetos que compõem o MB, aí você percebe que entupir o MB de variáveis ao invés de utilizar os presentes nos objetos é mais difícil de manter.
F
FernandoFranzini
Esta apostila simplesmente define um caso arquitetural dos muitos diferente que podem existir dentro de uma solução.
Não tem como responder suas perguntas de certo ou errado, uma vez que cada caso arquitetural soluciona requisitos em questão.
Uma aplicação pode ter 2, 3, 4 camadas e por vai dependendo da necessidade.
É possível dizer que talvez a arquitetura não seje a mais adequando para a solução em posse das justificativas.
No caso da apostila ele fez 3 camadas:
JSF->BO->DAO
Cada camada esta polimorficamente escondida com o objetivo de ser flexível ao ponto ser trocado por outras implementações…Mas repare que a camada BO simplesmente delegou as chamadas direta para o DAO sem fazer nada de interessante…kkkkkkkk
OU SEJA…fez atoa, sem motivos nenhum…
V
Vini_Fernandes
Entao efcjunior, eu prefiro utilizar a segunda opção por voce apontada: no lugar de vaaarios parametros no menaged bean eu trabalho com um objeto que encapsula todos esses parametros, por exemplo, no tela de cadastro de uma Pessoa, em vez de ter os parametros nome, idade, documento, etc, eu manipulo o estado do objeto Pessoa. Dessa forma a programacao fica mais “orientada a objetos” pois controlara o comportamento da tela de acordo com o estado do objeto Pessoa.
abrs…
E
efcjunior
A minha dúvida é porque tenho lido vários assuntos que desmotiva a utilização de bo, dto e vo por isso coloquei essa dúvida. Estou pensando ao invés de utilizar Bo, usar service que terá as minhas regras de negócio. O que vcs acham ?
Com relação a minha segunda dúvida, o objeto que terá meus atributos pode ser um entidy ?
V
Vini_Fernandes
O seu objeto pode, perfeitamente, ser um Entity Bean (uma classe anotada com o javax.persistence.Entity).
