[RESOLVIDO] JSF - Confusão entre Beans e Classes para Banco de Dados (DAO)

Front-end
#1

Boa tarde,
Estou desenvolvendo um projeto Web no qual utilizo JSF.
Tenho dois pacotes: Model (onde tenho os beans) , e Dao(onde tenho as classes dos beans relativas ao banco de dados)
Exemplo: Model.AlunoBean (possui os atributos nome, endereco, etc…e seus respectivos getters e setters)
Dao.AlunoDao (possui os métodos insere, busca, etc…)

A minha dúvida é: Em um momento, preciso preencher os dados de um ALuno e buscá-lo no banco de dados. NEsse momento tenho um formulário que preenche os atributos de um Beam de aluno (de sessao). Entao, depois preciso testar se o banco de dados possui esse Aluno Cadastrado, utilizando esse Bean com os atributos preenchidos. Mas, para realizar isso, o unico modo que vejo é preencher o bean que contém os métodos de busca, como se meu AlunoDao possuísse tanto esses métodos como os atributos de um AlunoBean. Mas, se eu fizer isso , para que serve o AlunoBean então?? Isso nao fere a OO?

Qual a melhor solução para isso?

Perdoe-me caso seja uma pergunta idiota , é a primeira vez que trabalho com JSF.
Desde já agradeço a Atenção.

Rodrigo Maia

#2

bean não seria o model

o legal e simples seria vc ter

AlunoDAO (grava umAluno no Banco)

AlunoBO (model) (chama o AlunoDAO para gravar)

AlunoBean ( controle) (recebe os dados da pagina e chama o AlunoBO para gravar)

paginaAluno.jsf (passa os dados para o aluno Bean)

#3

Okey, deixe-me ver se entendi.

A Classe AlunoBO então serve apenas para isolar o Bean e o Dao?
Ela deve possuir atributos? ou apenas recebê-los como parametro e repassar para o AlunoDao?

exemplo:

AlunoBean.grava() {
       
       AlunoBO.gravaDados(this);
}

AlunoBO.gravaDados(AlunoBean ab) {
        AlunoDAO.grava ( alunoBean.getNome(), etc)
}

Isso?
(e o que significa BO?? xD)

#4

BO - business Object ou Objeto de negocio

Não seria apenas para isolar o bean do DAO o BO é onde fica a logica da sua aplicação.

Existe varias formas de vc fazer isso, essa é apenas uma

O alunoBean que vc fala é do jsf? se for está errado assim

Você poderia fazer o seguinte

Domino - (Aluno GET E SET)
DAO - (AlunoDAO)
BO - (ALUNOBO)
MB - (ManagendBean do JSF AlunoMB )

class AlunoMB {
private Aluno aluno;
private AlunoBO alunoBO;

// get e set

public void gravar (Aluno aluno) {
alunoBO.gravar(aluno); (que por sua vez chama o DAO para gravar)

}

}

#5

Ela deve possuir atributos? ou apenas recebê-los como parametro e repassar para o AlunoDao?

depende se vc tiver que fazer alguma validação ai vc vai ter que ter atributoss…

#6

Credo… AlunoBO???
Só Aluno né? Menos feio…

driguh, o Aluno (ou AlunoBO :?) é uma classe que vai conter todos os atributos do aluno e métodos para obtê-los e configurá-los (gets e sets).
AlunoDAO vai usar o Aluno passado para algum método para efetuar alguma operação na base de dados.
AlunoBean vai ser a classe que vai estar ligada ao formulário e que, por sua vez, vai usar o Aluno e o AlunoDAO para conversar com o banco, além de informar ao controlador do JSF o caminho que o fluxo da aplicação deve seguir.

[]´s

#7

Pode ser Aluno ou AlunoBO não importa

O aluno que eu quis dizer ai seria o DTO só para passar os dados, como eu disse cada caso é um caso

1
vamos la… se eu tiver um Aluno com todas validaçoes , metodos , atributos, o AlunoBO não precisa ter um Aluno, pois o AlunoBO(Interface) ira atuar com um facade certo?

2
agora se eu tiver um Aluno só com atributo e get e set, O alunoBO sera a lógica de negocio aonde eu vou ter que ter uma aluno para fazer as validaçoes, não gosto dessa opção

3 É por fim eu eu posso ter o Aluno com todas validaçoes , metodos , atributos e não preciso ter um AlunoBO

Eu prefiro a 1 e a 3

#8

IMHO: Eu acho esse monte de camadas uma baita de uma frescura e de perda de tempo. Parece que os desenvolvedores estão mais preocupados em ter trocentas camadas para “manter o código manutenível” e competir para ver quem tem a arquitetura mais genérica do que ter somente o que é necessário. Enfim, gosto é gosto. Eu sempre prefiro a abordagem mais simples possível, desde que essa simplicidade não implique em gambiarras. Acho que falta um pouco de bom senso para decidir as camadas que a aplicação deve realmente ter.

#9

Hoje em dia, vc ter uma arquitetura robusta , para ter menas manutenção é tudo,

para o nosso amigo aconselho a opção 3

#10

[quote=erickfm8]Hoje em dia, vc ter uma arquitetura robusta , para ter menas manutenção é tudo,
para o nosso amigo aconselho a opção 3[/quote]
A é? O que é ser robusto? Quanto mais camadas, mais robusta é a arquitetura? É isso?

#11

Magina nunca isso hauhauuha,robusto e vc poder mudar por exemplo, de JSF para FLEX sem grandes alteraçoes, imagina se vc ter as validaçoes na view o no MB,quando mudar teque fazer tudo de novo… por isso vc ter uma camada aiii para não implicar nisto

#12

Então tah… Só que não vi ainda a diferenca entre ter mais camadas do que se precisa.

#13

concordo PLENAMENTE COM O @davidbuzatto…

hoje em dia mta gente faz “coisa demais” pra nada, no fim vira oq apelidaram de BOLOVO

abrassss

#14

Eu tbm concordo de nao ter camadas extras, somente se essa camada facilidar a flexibilidade de uma aplicação, principalmente na manutenção

#15

Okey, muito obrigado pelos esclarecimentos galera.

entendi, e vou fazer conforme o recomendado pelo nosso amigo davidbuzatto.

Vlw!

#16