como usar Transfer Object ?

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

fabgp2001 wrote:

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

]['s

Se for pensar assim (quanto menos classes melhor)...então faz tudo em uma classe só...os dados do aluno as regras de negocio e os metodos de persistencia... eu acho q fica muito feio!

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

Cara, realmente são opiniões muito distintas...

Mas cheguei nesta conclusão após enfrentar um projeto imenso para secretaria de fazenda envolvendo um Contribuinte, Impostos, Declarações.... Você já pensou no que seria um contribuinte com todas as suas regras de negócio e todos os seus atributos (sim, não há como negar que contribuinte possui atributos) em uma única classe, apenas para fazer com que Contribuinte seja responsável por tudo inerente ao contribuinte?! Concordo que seria lindo, que é o princípio de OO e tudo mais.. mas é inviável. Teríamos uma classe com mais de 15000 linhas fora a persistência. Pense em um obterContribuintePorFiltro() em um DAO. Você já pensou na marreta que é instanciar uma classe de contribuinte com todos os seus métodos de negócio e persistência (entendo que se o contribuinte é responsável por tudo relacionado ao contribuinte, seus métodos não devem se limitar apenas a validação) e retornar uma coleção destes para exibir numa grid?
Prefiro saber que um contribuinte é um Contribuinte e que este contém as informações do meu contribuinte. Quem vai validar e estabelecer regras de negócio relacionadas a algum procedimento feito com um contribuinte é o objeto de negócio apropriado. Quem vai persistir é o DAO apropriado. Na view eu recupero e seto as informações do contribuinte e passo o contribuinte para quem sabe o que fazer com o contribuinte!

Mas é questão de opinião e experiência.. Projeto grande faz a gente mudar a visão às vezes.

Rafael Nunes wrote:

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?

This message was edited 1 time. Last update was at 10/08/2005 10:58:04

mvcsouza wrote:
É uma forma muito elegante de resolver o problema e usa o principio de separação de responsabilidades favorecendo o desacoplamento do código.

Você pode me dizer como? Qual a responsabilidade do DTO e do tal BO?

A responsabilidade do DTO é pegar os dados do BO e passar para outro canto? Porque você não passa o BO?

Neste modelo você vai ter lógica de negócios altamente acoplada ao DTO, DTO altamente acoplado ao BO e View altamente ao DTO.

Lembre que dependência é transitiva, então tudo continua dependendo de tudo, e com mais o DTO no meio. Talvez assim seja melhor:

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ê.

Como assim?

Para você faz mais sentido criar uma classe B que é uma cópia burra de outra classe A, e que no fim B vai ser usado para gerar um A?

Por que você não gera A em primeiro lugar? Qual o benefício do itnermediário?

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.

Não existem (ou pelo menos não deveriam existir) "classes de dados" num modelo baseado em objetos.

mvcsouza wrote:
Concordo que seria lindo, que é o princípio de OO e tudo mais.. mas é inviável. Teríamos uma classe com mais de 15000 linhas fora a persistência. Pense em um obterContribuintePorFiltro() em um DAO. Você já pensou na marreta que é instanciar uma classe de contribuinte com todos os seus métodos de negócio e persistência (entendo que se o contribuinte é responsável por tudo relacionado ao contribuinte, seus métodos não devem se limitar apenas a validação) e retornar uma coleção destes para exibir numa grid?

Na verdade, me parece que o problema é um só: separação de responsabilidades. Pelo que você falou, seu entendimento de OOP o faria entupir o tipo com todos os métodos referentes a ele, na verdade você deveria separar as reponsabildiades entre outras classes.

Se você puder citar alguns casos problemáticos da tal classe, podemos trabalhar esse exemplo.

mvcsouza wrote:
Mas é questão de opinião e experiência.. Projeto grande faz a gente mudar a visão às vezes.

Bom, eu concordo em geral, mas não neste ponto. primeiro porque eu trabalho e trabalhei com projetos grandes e compelxos ao extremo, e os princípios de OOD foram formados baseados em projetos muito mais complexos do que eu ou a grande maioria dos frequentadores do GUJ pode sonhar em meter a mão.

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

pcalcado,

Compreendo, mas no seu modelo "Sem DTO" o que chega para o Servlet? Não há dependência entre MostraAluno e Aluno? Acho que é uma dependência entra as três camadas da mesma forma.. Prefiro trabalhar com aluno sendo apenas os dados do aluno. Quem tem que saber fazer os precessos em cima do aluno são as classes reponsáveis pelos processos. Veja que não discordo do seu ponto de vista com relação ao purismo OO. Mas não consigo concordar em manter uma estrutura pesada como um aluno quando tudo o que eu preciso na view são apenas os dados do aluno.. E se existe uma possibilidade do seu projeto crescer e você separar o container web do de aplicações para distribuir? Deixa o peso da aplicação só la no container e nas classes de negócio.. Acho que devemos expor o que é estritamente necessário para a camada. A view só precisa dos dados e passa a bola pra frente.
Por outro lado, se é para deixar tudo encapsulado em um Aluno, que este delegue para as classe especializadas como DAOs e BOs.. Acho que não podemos querer puristas sempre, se fosse assim, o Aluno tinha que se persistir!!! Para que DAO?

Eu considero que há muito pano na manga para discussão..

Assim, DTO é lixo e só serve pra uma coisa, consertar uma falha dos EJBs, quem não usa EJB não deveria estar usando esse tipo de gambiarra.

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

mvcsouza wrote: Por outro lado, se é para deixar tudo encapsulado em um Aluno, que este delegue para as classe especializadas como DAOs e BOs.. Acho que não podemos querer puristas sempre, se fosse assim, o Aluno tinha que se persistir!!! Para que DAO?

Você consegue criar alunos capazes de se persistir e mantendo um código legível...

Como já rolou em outras discussões aqui no guj, Active Record é interessantíssimo, e além do mais, existem outras maneiras de seu objeto ser capaz de se persistir, desde que ele acesse uma interface que possui os métodos de persistência!

Ou seja, vc teria uma classes com seus métodos de persistência desacoplado da sua lógica de negócio, e sua classe de negócio é que diz quando ele deve ser persistido ou não!

This message was edited 1 time. Last update was at 10/08/2005 11:52:47

mvcsouza wrote:
Compreendo, mas no seu modelo "Sem DTO" o que chega para o Servlet? Não há dependência entre MostraAluno e Aluno? Acho que é uma dependência entra as três camadas da mesma forma..

Sim, falta a seta entre eles.

A pergutna é, para cada objeto de negócio você pode depender apenas do objeto em questão ou gerar uma dependência desnecessária utilizando um DTO. Para um exemplo com uma classe não aprece muito, mas isso vai crescer expotencialmente num sistema de verdade, e cada vez que você alterar uma coisa, vai alterar todo o ciclo de dependência.

O ponto é: em termos de acoplamento e dependência, DTO só piora.

mvcsouza wrote:
Prefiro trabalhar com aluno sendo apenas os dados do aluno. Quem tem que saber fazer os precessos em cima do aluno são as classes reponsáveis pelos processos.

Isso é programação procedural e existem ferramentas melhores para programar assim do que Java.

mvcsouza wrote:
Veja que não discordo do seu ponto de vista com relação ao purismo OO. Mas não consigo concordar em manter uma estrutura pesada como um aluno quando tudo o que eu preciso na view são apenas os dados do aluno..

Vamos analisar o fluxo:
1 - Com DTO

2 - Sem DTO

mvcsouza wrote:
E se existe uma possibilidade do seu projeto crescer e você separar o container web do de aplicações para distribuir? Deixa o peso da aplicação só la no container e nas classes de negócio.. Acho que devemos expor o que é estritamente necessário para a camada. A view só precisa dos dados e passa a bola pra frente.

Semrpe existe essa possiblidade, um bom projetista vais aber avaliar o custo/beneficio de toda flexibilidade.

Nesse caso especifico, você está falando de um cenário onde um DTO é um bom negócio. O que nós estamos discutindo é onde ele não é um bom negócio.

mvcsouza wrote:
Por outro lado, se é para deixar tudo encapsulado em um Aluno, que este delegue para as classe especializadas como DAOs e BOs.. Acho que não podemos querer puristas sempre, se fosse assim, o Aluno tinha que se persistir!!! Para que DAO?

Acho que entendi seu ponto. O poblema é que você está colocando responsabilidades demais em Aluno.

Um aluno tem por responsabilidade executar suas regras de negócio (entrar em um curso, sair do curso, retornar seu boletim, sei lá...), o que você está falando é em misturar as responsabilidades de outras classes no aluno, por isso pedi um exemplo

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

Thiago Senna wrote:
, desde que ele acesse uma interface que possui os métodos de persistência!

Ou seja, vc teria uma classes com seus métodos de persistência desacoplado da sua lógica de negócio, e sua classe de negócio é que diz quando ele deve ser persistido ou não!

Concordo, mas a interface que possui os métodos de persistência seria implementada por uma classe especializada, correto? E não o próprio Aluno como no caso em questão.

Essa é a discussão: até que ponto deve-se embutir funcionalidade numa classe que representa o Aluno e a partir de quando deve-se delegar para classes especializadas? Eu sou a favor do TO puro.. Classes especializadas cuidariam do resto, mesmo com o efeito colateral da dependência do TO entre as camadas, que na minha opinião é perfeitamente aceitável e administrável. Alguma coisa tem que ser passada entra as camadas(View, Controller, Model), senão nào há comunicação entre elas...

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

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

Code-folding são aquelas setinhas que aparecem do lado do código para poder abrir/fechar o código. Assim ficam escondidas as linhas de código que não precisa ficar olhando o tempo todo. Acho que tem no Netbeans!

Sobre setters, é exatamente o contrário do que falou hehe quebrar o encapsulamento é chamar esses getters/setters de fora. Para preencher os atributos de seu objeto, use o construtor

Sobre a ausência de getters/setters, leia meus favoritos! Isso foi amplamente discutido aqui no fórum, recomendo a leitura.

jdeveloper wrote:

fabgp2001 wrote:

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

]['s

Se for pensar assim (quanto menos classes melhor)...então faz tudo em uma classe só...os dados do aluno as regras de negocio e os metodos de persistencia... eu acho q fica muito feio!

jdeveloper,

Mas estamos falando de duas classes que dizem respeito ao mesmo Objeto, no caso aluno. Nao da pra generalizar como tu fez.

]['s

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

mvcsouza entenda que não estamos falando que DTOs nunca devem ser usados. Só estamos dizendo que só devem ser usados em ambientes altamente distribuídos APÓS ter certeza absoluta que a carga de rede está exagerada.

E também não estamos falando para colocar todo o código dentro de Aluno. Mas é dividir as responsabilidades com coerência:

Ao inves de:

Fazer:

Como deve bem saber por ter participado de projetos grandes, a primeira abordagem rapidamente se torna um inferno de manutenção com código repetido espalhado por todo o projeto.

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

Lipe wrote: Como deve bem saber por ter participado de projetos grandes, a primeira abordagem rapidamente se torna um inferno de manutenção com código repetido espalhado por todo o projeto.

Muito bém colocado! Com certeza, este é um fator que pode ser um diferencial em um projeto de grande porte!

Hoje estou fazendo refactoring em uma aplicação o o programador usou bastante buffer.write()., buffer.newLine() e buffer.flush(); sempre usando a mesma sequência! O texto que estava sendo passado dentro dos métodos Estava em inglês!

Dái, me abriram um bug para passar para Português! Pronto! Ferrou!
Essa rotina que usava 5 linhas se repete em média 12x distribuidamente em 17 queridas classes!

17 x 12 X 5 = 1020

Agora com meu refactoring, o q antes estava usando 5 linhas começara a uasr 2 linhas, entaum:

17 * 12 * 2 = 408

logo

1020 - 408 = 620

Nessa brincadeira estou eliminando 620 linhas de código desnecessárias.

Acho que este seria um exemplo simples para ilustrar como algumas rotinas repetitivas (mesmo que bém organizadas) podem ser simplificadas!

Fazer este refactoring nisso está super dispendioso, e vou com certeza levar mais de um dia para terminar!

mvcsouza, em minha opinião, acho que sempre que possível é melhor optar pela simplicidade! Apesar de vc gostar desta estrutura com TO, acredito que não usar o TO torne a aplicação mais simples, e até mesmo mais desafiador.

Abraços!
Thiago

This message was edited 1 time. Last update was at 10/08/2005 15:09:03

caro pcalcado,

Temos uma percepçào um pouco diferente do que seria o DTO, ou de como usá-lo. No diagrama que você mostrou, com relação às sequencias do modelo com DTO, não há a necessidade de se persistir o estado no objeto Aluno, conforme você ilustrou. Isto já foi feito no DTO e esta é justamente a sua função, manter estado. Se o DTO mantém estado, não há necessidade de se criar um objeto Aluno e restaurar o estado a partir de um AlunoDTO, nem o contrário.

Veja um exemplo de como seria um pseudo fluxo em código:

Esta é a seqüência. Portanto, perceba que não há necessidade de injetar o estado do aluno em um objeto Aluno a partir de um AlunoDTO. O alunoDTO em si é o estado. Penso que o objeto Aluno sugerido por você existiria como um BO, no caso da necessidade de validações especiais e realizações de regras de negócio durante determinada operação sobre o aluno.

<br>

Isto ao meu ver especializa o código e não espalha código como alguns colegas disseram. O desenvolvedor sabe com base no padrão onde está cada especialidade de código, seja validação, persistência e negócio. Além disso, a comunicaçào das mensagens entre as camadas se dá de forma muito mais otimizada, e de quebra eu não preciso alterar o meu código se algum dia precisar fazer uma chamada remota!

Abraços,

This message was edited 2 times. Last update was at 10/08/2005 15:25:44

mvcsouza wrote:
Temos uma percepçào um pouco diferente do que seria o DTO, ou de como usá-lo. No diagrama que você mostrou, com relação às sequencias do modelo com DTO, não há a necessidade de se persistir o estado no objeto Aluno, conforme você ilustrou. Isto já foi feito no DTO e esta é justamente a sua função, manter estado. Se o DTO mantém estado, não há necessidade de se criar um objeto Aluno e restaurar o estado a partir de um AlunoDTO, nem o contrário.

Então o que voce está usando não é um DTO/VO/TO. Estes objetos existem apra transmitir dados, não para ser o estado de uma entidade.

No seu caso, então, meus diagramas estão errados, porque existe uma dependência de aluno para o DTO.

O que você está fazendo é simples:

AlunoDTO -> Estado
Aluno(BO)-> Comportamento

Ou seja: separando um objeto em duas classes.

Você programa em C? Se programa, vejamos:

aluno.h:

aluno.c

Qual a diferença?

Otimizada por que?

Você cria uma classe a mais para cada classe de negocio hoje para evitar que num futuro que pode acotnecer ou não (o mais provável) você não precise criar uma classe para todas as operações remotas (que pode ser uma Session Façade, por exemplo)?

Me diz qual a vantagem de fazer isso e criar uma Façade Remota que retorna e recebe objetos "Aluno".

E, novamente, qual exemplo você dá de uma classe que tenha tanta regra de negócio que fica impraticável utilizar OOP?

Um outro problema no codigo eh o servlet tocando a camada de persistencia diretamente, utilize uma camada de aplicação leve para isso.

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