como usar Transfer Object ?

LIPE wrote:
Como??

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

) o memento nos objetos do cliente, fazendo um update.

Na real é um jeito de evitar assemblers.

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

Shoes: mas para que juntar os mementos num DTO e não os próprios objetos?

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

Quantos atributos suas classes costumam ter a ponto de "ficar muito grande" colocar mais uma meia dúzia de métodos de negócio? @.@

LIPE wrote:Shoes: mas para que juntar os mementos num DTO e não os próprios objetos?

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.

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

LIPE wrote:

Quantos atributos suas classes costumam ter a ponto de "ficar muito grande" colocar mais uma meia dúzia de métodos de negócio? @.@

é 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?

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

Shoes: entendi

realmente boa idéia.

jdeveloper: ah ... getters e setters

isso faz mal cara hehe

jdeveloper wrote:

LIPE wrote:

Quantos atributos suas classes costumam ter a ponto de "ficar muito grande" colocar mais uma meia dúzia de métodos de negócio? @.@

é 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?

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

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

fab, penso que ele se referiu ao tamanho do código.

fab

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

LIPE wrote:fab, penso que ele se referiu ao tamanho do código.

fab

é isso mesmo...o código fica muito grande...a manutenção fica mais difícil...

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

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?

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

LIPE wrote:
Na sua IDE não tem code-folding? Já tentou não usar getters e setters?

não sei o q é code-folding

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?

Thread.start() Membro desde: 26/01/2005 11:29:34 Mensagens: 42 Offline

Cara, falando sério...

Não acho que o uso de DTOs deva ser condenado em ambientes não-distribuídos. É uma forma muito elegante de resolver o problema e usa o principio de separação de responsabilidades favorecendo o desacoplamento do código. Um problema que eu vejo em deixar o DTO de lado e criar uma classe que englobe tudo como no caso citado acima (Aluno), é o seguinte. Quando o DAO vai buscar alunos por classe por exemplo, você vai criar uma coleçào de alunos (classe Aluno com dados e métodos de negócio) e retornar para o view. Fica meio sem quê nem pra quê.
Além disso, o cara aí em cima lembro muito bem a facilidade em usar este padrão com os frameworks MVC que assumem este que DTO será o padrão usado na modelagem das classes de dados.

mvcsouza wrote:Não acho que o uso de DTOs deva ser condenado em ambientes não-distribuídos. É uma forma muito elegante de resolver o problema e usa o principio de separação de responsabilidades favorecendo o desacoplamento do código.

Discordo. O princípio de separação de responsabilidade alega que quem detém a informação é o responsável pela ação. Mas os DTOs não são detentores de informação nenhuma, é só um objeto repleto de atributos distintos.

mvcsouza wrote:
Um problema que eu vejo em deixar o DTO de lado e criar uma classe que englobe tudo como no caso citado acima (Aluno), é o seguinte. Quando o DAO vai buscar alunos por classe por exemplo, você vai criar uma coleçào de alunos (classe Aluno com dados e métodos de negócio) e retornar para o view. Fica meio sem quê nem pra quê.

Um Aluno englobar o que é inerente ao aluno não vejo como problema. Aliás, o que há de errado em se retornar um Aluno quando se solicita um Aluno?Ao menos para mim é estranho você retornar um objeto alienígena toda vez que solicitar uma entidade.

mvcsouza wrote:
Além disso, o cara aí em cima lembro muito bem a facilidade em usar este padrão com os frameworks MVC que assumem este que DTO será o padrão usado na modelagem das classes de dados.

Qual framework em específico assume que você utilizará um DTO?

jdeveloper wrote:

LIPE wrote:fab, penso que ele se referiu ao tamanho do código.

fab

é isso mesmo...o código fica muito grande...a manutenção fica mais difícil...

Haaaa..nesse caso esquece os get e set burro sem necessidade.

E falando nisso, fazer em duas classes nao ficaria maior nao? Alem de ter um outro .java enchendo o saco.

]['s

This message was edited 1 time. Last update was at 10/08/2005 10:26:21

Olá!

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

1 - Talvez vc possa melhor seu modelo. Por exemplo, quando houver muita coisa, talvez vc possa quebrar esta classe em outras responsabilidades. Por exemplo, vc poderia criar uma classe Endereco. Na classe endereco vc coloca o endereco, cidade, bairro, rua, cep e etc...
Tente identificar em suas classes que é possível melhorá-las, e desacoplar dados em comum em uma outra classe!

2 - Não vejo problemas caso haja 20 atributos e 40 getters e setters em sua classe. Se vc não tiver como fugir dos getters e setters, e só vc se organizar. Por exemplo:

Se organize, que cria algumas convenções como por exemplo, deixe todos os seus métodos de negócio no final da classe! Assim, se vc tiver que trabalhar em algum método de negócio, vc sabe que a única coisa a fazer é se mover para o final do arquivo e encontrar o seu método de negócio!

Com os recursos das IDE´s que temos hoje, como o eclipse por exemplo, segure o control e clique com o mouse em cima do método que ele já te leva para a implementação do método!

Não há pq separar uma classe contendo só os métodos de negócio!

Abraços!
Thiago Senna

mvcsouza wrote:...uma forma muito elegante de resolver o problema...

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