como usar Transfer Object ?

wellmattos wrote:Eu gosto de usar DTO nas minhas arquiteturas, sendo elas distribuidas ou não, por exemplo para montar frameworks vc precisa utilizar um DTO para transferir os dados de uma camada para outra abstraindo assim por exemplo qual a interface que vc utiliza e deixando a regra de negocio limpa.. utilizando apenas seus BO na camada de negócio não levando ele para a camada de interface..

Aí você faz:

E tem um DTO/TO/VO:

Exatamente igual? Para que?

wellmattos wrote:
por exemplo para montar frameworks vc precisa utilizar um DTO para transferir os dados de uma camada para outra abstraindo assim por exemplo qual a interface que vc utiliza e deixando a regra de negocio limpa..

Para usar frameworks decentes (ou até indecentes como Struts) você não rpecisa de VO. Aliás, você só rpecisa deles numa arquitetura altamente distribuída (que as blueprints do JEE sempre prezam, mas que quase nunca acotnece no mundo real).

O que você chama de montar frameworks?

JavaChild Membro desde: 04/08/2005 08:55:58 Mensagens: 132 Offline

pcalcado wrote:

Vamos devagar, do que se trata sua aplicação?

É o seguinte:

Eu tenho q fazer um sistema que faz a inscrição de um usuário online.
Então ele tem basicamente que preencher um cadastro pessoal e de acordo com o tipo de opcao de inscricao q ele escolhe o sistema exibe uma ou outra opção nas telas.

Eu pensei em fazer o seguinte:

Usar um jsp como minha camada de apresentação.
Usar um servlet como controlador.
Usar um BO e um DAO como meu model.

Então o usuário preenche o cadastro(jsp) e envia para o servlet. Esse servlet pega os dados do usuário, armazena em um objeto e envia para a minha camada de negócios para basicamente validar campos.
Se os dados digitados pelo usuário estiverem corretos eu passo esse objeto para a minha camada de negócios para q ele possa ser persistido.

Entendeu?

Isso não está correto?

This message was edited 2 times. Last update was at 09/08/2005 12:14:22

Está correto. E basta um objeto Aluno, um AlunoDAO e um CadastroServlet para isso

JavaChild Membro desde: 04/08/2005 08:55:58 Mensagens: 132 Offline

LIPE wrote:Está correto. E basta um objeto Aluno, um AlunoDAO e um CadastroServlet para isso

class CadastroServlet { public void execute() { Aluno aluno = new Aluno(); // popula o objeto aluno com os dados da request if( !aluno.validate() ) { // redireciona de volta com os error return; } AlunoDAO dao = new AlunoDAO(); dao.save( aluno ); // ou quem sabe aluno.save(); // aluno que chama o DAO } }

não seria melhor criar mais uma classe para validar os dados...ao invés de validar os dados dentro do servlet...?

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4641 Offline

Existem diversas maneiras de validar dados

escolha a sua hehe

Eu gosto de usar strategy:

A implementação de ValidationStrategy varia.

pcalcado wrote:
Aí você faz:
class Usuario{ private String nome = null; private String endereço = null; private int idade = 0; //gets e sets }

E tem um DTO/TO/VO:
class UsuarioVo{ private String nome = null; private String endereço = null; private int idade = 0; //gets e sets }

Exatamente igual? Para que?

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:

Assim deixando a minha classe "mais leve" pois não tenho métodos para serem persistidos?

This message was edited 2 times. Last update was at 09/08/2005 12:33:45

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

Forum Spammer Membro desde: 11/02/2005 08:08:02 Mensagens: 1511 Offline

jdeveloper wrote: 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?

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!

JavaChild Membro desde: 04/08/2005 08:55:58 Mensagens: 132 Offline

Thiago Senna wrote:

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!

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?

Forum Spammer Membro desde: 11/02/2005 08:08:02 Mensagens: 1511 Offline

jdeveloper wrote:

Thiago Senna wrote:

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!

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?

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!

JavaChild Membro desde: 04/08/2005 08:55:58 Mensagens: 132 Offline

Obrigado a todos pela ajuda...alguns conceitos estão muito mais claros agora...

Abraços

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4641 Offline

JDeveloper, o que estamos tentando te dizer é que não há necessidade de ter AlunoBean e AlunoBO

Pode nos dizer por que acha que é necessário? Ou é uma questão de gosto mesmo?

kina wrote:
Assim deixando a minha classe "mais leve" pois não tenho métodos para serem persistidos?

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.

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4641 Offline

pcalcado wrote:O padrão memento pode salvar vidas neste caso.

Como??

JavaChild Membro desde: 04/08/2005 08:55:58 Mensagens: 132 Offline

LIPE wrote:JDeveloper, o que estamos tentando te dizer é que não há necessidade de ter AlunoBean e AlunoBO

Pode nos dizer por que acha que é necessário? Ou é uma questão de gosto mesmo?

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?

Notícias, artigos e o maior fórum brasileiro sobre Java