Uma pergunta.
Qual a diferença dos dois? (Aluno, AlunoVO) ??
Por acaso o Aluno tem regra? o aluno faz persistência?
Porque no meu VO eu não deixo assim:
class UsuarioVo{
public String nome = null;
public String endereço = null;
public int idade = 0;
}Assim deixando a minha classe “mais leve” pois não tenho métodos para serem persistidos?
Serialize uma classe com 10 métodos e outra com 100 métodos e compare os tamanhos dos arquivos. Se o “overhead da sua rede” for grande demais, use VO 
[quote=jdeveloper] Só uma coisa… vc disse pra esquecer o bo…mas não é importante ter uma camada de negócios?
o código fica bem mais organizado? [/quote]
Vc precisa saber trabalhar com sua camada de negócio, não com o Desgin Pattern Business Object. 
No dia a dia, vc vai ver que o pessoal nem fala em BO, eles falam logo classes de negócio.
Por exemplo, no exemplo que o Lipe passou, a classe Aluno possui um método validate! E vc perguntou se não seria melhor criar uma outra classe para cuidar da validação.
Isso vai do seu gosto, mas já que está usando OO, nada melhor do que o próprio aluno validar seus próprios dados!
Voltado ao assunto BO, a classe Aluno seria equivalemente a classe AlunoBO. Subtende-se que a classe Aluno é a classe de negócio e acabo! Business Object é um design pattern que até hoje eu naum sei pq criaram ele!
[quote=Thiago Senna]
Voltado ao assunto BO, a classe Aluno seria equivalemente a classe AlunoBO. Subtende-se que a classe Aluno é a classe de negócio e acabo! Business Object é um design pattern que até hoje eu naum sei pq criaram ele![/quote]
Entendi o q vc quer dizer…
Mas eu to pensando em fazer uma classe CadastroServlet, uma AlunoBean, uma AlunoBO e uma AlunoDAO…
assim a classe q vc chamou de Aluno ficaria só pra armazenar os dados do aluno(AlunoBean).
o q vc acha?
[quote=jdeveloper][quote=Thiago Senna]
Voltado ao assunto BO, a classe Aluno seria equivalemente a classe AlunoBO. Subtende-se que a classe Aluno é a classe de negócio e acabo! Business Object é um design pattern que até hoje eu naum sei pq criaram ele![/quote]
Entendi o q vc quer dizer…
Mas eu to pensando em fazer uma classe CadastroServlet, uma AlunoBean, uma AlunoBO e uma AlunoDAO…
assim a classe q vc chamou de Aluno ficaria só pra armazenar os dados do aluno(AlunoBean).
o q vc acha?[/quote]
O que eu acho, péssimo…
Criar uma classe AlunoBean e outra AlunoBO é uma coisa muito feia!
O exemplo que o pessoal passou é um espetáculo, onde Vc tem uma classe Aluno, AlunoDAO e o CadastraAlunoAction (Controle)!
Se vc quer não quer o método validate dentro da classe aluno (aluno.validate()), então cria uma classe só pra validação, tipo
ValidateUtil, NegociaValidateUtil, sei lá!
Uma outra possibilidade é vc fazer a validação dos dados do aluno no controle. Se o seu controle + view garantir que não entrará dados inválidos na camada de negócio, então vc pode optar por não usar a validação dentro da classe aluno!
Obrigado a todos pela ajuda…alguns conceitos estão muito mais claros agora…
Abraços
JDeveloper, o que estamos tentando te dizer é que não há necessidade de ter AlunoBean e AlunoBO :thumbup:
Pode nos dizer por que acha que é necessário? Ou é uma questão de gosto mesmo?
[quote=kina]
Assim deixando a minha classe “mais leve” pois não tenho métodos para serem persistidos?[/quote]
Num DTO de verdade, utilizado para transmitir dados por uma rede e não para pegar dados do DAO e passar pro Joãozinho, você vai querer minimizar o tráfego, então é bom observar bastante os seus casos de uso e achar a melhor maneira de empacotar dados dos objetos de verdade em DTOs gordos que só servem para isso.
O padrão memento pode salvar vidas neste caso.
Como??
[quote=LIPE]JDeveloper, o que estamos tentando te dizer é que não há necessidade de ter AlunoBean e AlunoBO :thumbup:
Pode nos dizer por que acha que é necessário? Ou é uma questão de gosto mesmo?[/quote]
Eu acho q o código fica mais limpo se vc usar uma classe bean só pra armazenar dados do usuário e outra classe para realizar as regras de negócio.
No meu caso eu pretendo usar uma classe para armazenar os dados obtidos em várias telas. A cada tela que o usuário vai preenchendo eu vou adicionando os dados a essa classe.
Se eu armazenar os dados do usuário e as regras de negócio somente em uma classe essa classe vai ficar muito grande…o q eu acho ruim.
Entendeu?
[quote=LIPE]
Como??[/quote]
Pegue seu objeto, extraia um memento. Junte todos os mementos dos objetos que precisar passar pela rede, empacote num grande DTO e mande pela rede.
Na outra ponta, injete (palavrinha na moda 8) ) o memento nos objetos do cliente, fazendo um update.
Na real é um jeito de evitar assemblers.
Shoes: mas para que juntar os mementos num DTO e não os próprios objetos?
Quantos atributos suas classes costumam ter a ponto de “ficar muito grande” colocar mais uma meia dúzia de métodos de negócio? @.@
[quote=LIPE]Shoes: mas para que juntar os mementos num DTO e não os próprios objetos?
[/quote]
Um memento deve ser menor (em recursos, memória, blablabla) que um objeto inteiro, e ele tem o mínimo necessário apra recompôr o estado.
Quando você tem problemas numa rede a ponto de realmente precisar de DTOs, passar o mínimo possível de bytes pelo fio é essencial.
[quote=LIPE]
Quantos atributos suas classes costumam ter a ponto de “ficar muito grande” colocar mais uma meia dúzia de métodos de negócio? @.@[/quote]
é uma classe de cadastro…então tem nome,idade,rg,cep,cpf,etc…
enfim…tem pelo menos 20 atributos…
20 atributos + 20 get + 20 set + os métodos de negócio…é bastante, não acha?
Shoes: entendi realmente boa idéia.
jdeveloper: ah … getters e setters 
isso faz mal cara hehe
[quote=jdeveloper][quote=LIPE]
Quantos atributos suas classes costumam ter a ponto de “ficar muito grande” colocar mais uma meia dúzia de métodos de negócio? @.@[/quote]
é uma classe de cadastro…então tem nome,idade,rg,cep,cpf,etc…
enfim…tem pelo menos 20 atributos…
20 atributos + 20 get + 20 set + os métodos de negócio…é bastante, não acha?[/quote]
Nao. 
Faca a dica do Lipe. Pegue esse teu objeto e serialize ele em disco. Pegue uma lista com pequena quantidade desse objeto dentro e serialize em disco tb, pegue uma lista com grande qunatidade de objetos deste dentro e serialize tb. Verifique o tamanho e faca sua avaliacao.
É a melhor maneira para ter uma boa conclusao do que é grande ou nao para trafegar na rede.
]['s
fab, penso que ele se referiu ao tamanho do código.
[size=8]fab :XD:[/size]
[quote=LIPE]fab, penso que ele se referiu ao tamanho do código.
[size=8]fab :XD:[/size][/quote]
é isso mesmo…o código fica muito grande…a manutenção fica mais difícil…
Para mim difícil é manter um relacionamento que só faz sentido para “o código não ficar muito grande” hehe
Na sua IDE não tem code-folding? Já tentou não usar getters e setters?
[quote=LIPE]
Na sua IDE não tem code-folding? Já tentou não usar getters e setters? :D[/quote]
não sei o q é code-folding :roll: atualmente eu to usando o netbeans 4.1
como é que eu vou preencher os meus atributos sem utilizar set? tiro o encapsulamento? melhor não,neh?
como é que eu vou pegar os dados para depois persistir sem usar get?