como usar Transfer Object ?

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

pcalcado wrote:
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)?

Nào entendi muito bem esta questão. Pelo que percebi, você atribui ao fato de se criar um Session Façade a solução das chamadas remotas? O que quis dizer foi que meus objetos DTO usados hoje apenas para manutenção de estado na aplicação seriam a forma mais adequada para transferência numa chamada remota, ou seja, não precisaria me preocupar com estruturas mais otimizadas para tranasferência de minhas entidades. As entidades já são esta estrutura.

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

Não sei se você usa esta prática em aplicações distribuídas com seus projetos, mas aqui é comum a criação de um session façade para cada módulo do sistema. Por exemplo, um façade para um módulo de Mátricula, um Façade para o módulo de cobrança, um façade para o módulo de Controle de Notas... Como a aplicação já trabalha desta forma (recebendo e devolvendo entidades DTOs) bastaria adicionar a camada EJB sem alterar muito as assinaturas. Claro que atentando para o padrão Session Façade (seu conceito).

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

Pense numa declaração de imposto que envolva dependentes, valores, bens, dados do contribuinte, rendas... E a quantidade gigantesca de regras associadas a cada variação em cada um de seus atributos no momento de sua criação?

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

Realmente, não entendi.. No código do exemplo, o Servlet chama o gerenciador. Por favor, exemplifique o caso com um exemplo citando o nome da técnica ou padrão que deveria ser usado.

Valeu,

T+,

This message was edited 1 time. Last update was at 10/08/2005 16:37:18

Ola,

mvcsouza wrote:
Nào entendi muito bem esta questão. Pelo que percebi, você atribui ao fato de se criar um Session Façade a solução das chamadas remotas? O que quis dizer foi que meus objetos DTO usados hoje apenas para manutenção de estado na aplicação seriam a forma mais adequada para transferência numa chamada remota, ou seja, não precisaria me preocupar com estruturas mais otimizadas para tranasferência de minhas entidades. As entidades já são esta estrutura.

Existe uma diferença entre layer e tier. Utilizar DTOs para passar entre layers é besteira se stas ficam na mesma tier. Essa é a discussão. Se você ler o tópico, vai ver que todos aqui comentaram que DTO é sim válido para chamadas remotas. É um mal necessário.

Entretanto, pelo menos num ambiente normal, dificilmente você terá interfaces remotas que justifiquem um DTO. Mesmo onde você tem tais interfaces, é conveniente utilizar um profiler, verificar o tamanho dos objetos serializados, tráfego na rede e todas as outras variáveis para definir o DTO a ser utilizado, lembro que não rpecisa haver um mapeamento de 1 para 1 entre DTO e objeto, pelo contrário, é melhor você colcoar vários objetos num só DTO para economizar recursos.

mvcsouza wrote:
Não sei se você usa esta prática em aplicações distribuídas com seus projetos, mas aqui é comum a criação de um session façade para cada módulo do sistema. Por exemplo, um façade para um módulo de Mátricula, um Façade para o módulo de cobrança, um façade para o módulo de Controle de Notas... Como a aplicação já trabalha desta forma (recebendo e devolvendo entidades DTOs) bastaria adicionar a camada EJB sem alterar muito as assinaturas. Claro que atentando para o padrão Session Façade (seu conceito).

Sou contra soluções tamanho-unico, mais ainda se envolve EJB. nos projetos em que trabalho varia sempre, e semrpe tentando eliminar ao máximo de EJB em função de tecnologias mais leves.

Pergunta simples:

Sabendo que o problema em trafegar dados em um sistema distribuído numa rede é basicamente o RPC e necessidade constante de trocar dados o tempo todo, o padrão DTO é utilizado para minimizar estas chamadas. Se seus DTOs são menores que um objeto de verdade, qual a vantagem em utilizá-los ao invés de apenas mandar o objeto?

Economizar alguns bytes na transmissão? Vale a pena aumentar a complexidade do seu projeto, criando uma classe só com estado, outra só com comprotamento, só para passar menos dados numa rede?

O real problema de transmissão em sistemas distribuídos não é o tamanho dos objetos individualmente, que geralmente é insignificante, mas sim a quantidade de vai-e-vem de dados o tempo todo e o tamanho do grafo de objetos que deve ser passado, que vaid epender basicamente do que o cliente vai fazer com os objetos.

No exemplo, se AlunoDTO tem uma referencia a um CursoDTO (ou curso BO, nao sei como vc prefere relaciona-los), e CursoDTO tem referencias a diversos outros AlunoDTO, que tem referencias a outros CursoDTo que por sua vez referenciam mais AlunoDTO... como seu DTO te ajuda a melhorar o desempenho?

A discussão já está descambando para a melhor estratégia em um DTO, mas o meu ponto é que não vale a pena complicar sua camada de negocios e criar classes que não obedecem os principios basicos de OOP para um requisito que:

1 - Não é onipresente (pelo contrário, é bem infrequente. Quantos aqui tem a camada de negocios em um servidor e a de web em outro na maioria dos projetos? Quantos viram isso uma ou duas vezes? Quantos nunca viram isso?)

2 - Pode existir, mas não ser necessário o uso de DTO (POJOs podem dar cotna do recado em muitos casos)

3 - Se realmente necessário, pode ser solucionado de uma forma melhor, usando Transfer Object Assemblers em cima de objetos de negócio.

mvcsouza wrote:
Pense numa declaração de imposto que envolva dependentes, valores, bens, dados do contribuinte, rendas... E a quantidade gigantesca de regras associadas a cada variação em cada um de seus atributos no momento de sua criação?

Penso, mas não consigo entender porque você não consegue distribuir isso em objetos ao invés de usar registros.

mvcsouza wrote:
Realmente, não entendi.. No código do exemplo, o Servlet chama o gerenciador. Por favor, exemplifique o caso com um exemplo citando o nome da técnica ou padrão que deveria ser usado.

A técnica se chama Programação em Camadas e Separaçãod e Responsabilidades, você poderia implementar uma Camada de Aplicação (Application Layer) utlizando, por exemplo um façade, ao invés de acessar o DAO de vez, atropelando a Camada de Negócios.

[]s

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

Com relação às suas perguntas direcionadas a performance de rede.. Não sei, mas penso que a transferência de objetos burros será inquestionavelmente menos custosa em qualquer situação do que um objeto de mesma entidade com inteligência.. Mas o fato do objeto conter listas e mais listas de referências a outros objetos seria um problema em qualquer situação numa tentativa de minimizar os custo de transferência. Este caso normalmente seria feito via gambiarra como você conhece o DTO!

Com relação ao último item, o código de exemplo já não está fazendo isso, na medida em que ele faz uma chamada ao Gerenciador ao invés de chamar diretamente o DAO?

Com relação a ser ou não burrice ou horrível passar Objetos burros na mesma layer... Realmente não considero. Acho que é uma forma padronizada e unificada de se representar a entidade.. A questão agora em minha mente é:

Até onde vai a inteligência da Entidade?? Aluno tem que saber fazer o que com ele mesmo? Quando eu passo para o BO??

mvcsouza wrote:
Não sei, mas penso que a transferência de objetos burros será inquestionavelmente menos custosa em qualquer situação do que um objeto de mesma entidade com inteligência.. Mas o fato do objeto conter listas e mais listas de referências a outros objetos seria um problema em qualquer situação numa tentativa de minimizar os custo de transferência. Este caso normalmente seria feito via gambiarra como você conhece o DTO!

Bom, isso é fácil de testar

Como falei, fazendo o teste você vai comprovar que não importa passar 50kb a menos, o que importa é minimizar a comunicação, apra isso um DTO empacota tudo que o cliente vai rpecisar, esta é sua finalidade.

Como num mesmo nó você não tem dificuldade em comunicação (está tudo no mesmo espaço de endereçamento), você não vai precisar de um DTO.

mvcsouza wrote:
Com relação ao último item, o código de exemplo já não está fazendo isso, na medida em que ele faz uma chamada ao Gerenciador ao invés de chamar diretamente o DAO?

Perdão, você está certo, eu não havia vista que começava outro arquivo no meio da tag [ code ], era isso que eu estava dizendo.

mvcsouza wrote:
Com relação a ser ou não burrice ou horrível passar Objetos burros na mesma layer... Realmente não considero. Acho que é uma forma padronizada e unificada de se representar a entidade..

Dê uma lida em alguns textos sobre o assunto:
http://www.martinfowler.com/bliki/AnemicDomainModel.html
http://www.theserverside.com/news/thread.tss?thread_id=34278

mvcsouza wrote:
A questão agora em minha mente é:

Até onde vai a inteligência da Entidade?? Aluno tem que saber fazer o que com ele mesmo? Quando eu passo para o BO??

O BO é o aluno. Isso resume OOP. Estado e comprotamento no mesmo construto.

Agora se você está pergutnando se o aluno tem que ter toda a lógica referente a ele, a respsota é simplesmente: não. Por que? Por que muitas relações em que o aluno participa são de responsabilidade de outros objetos, e devem ser distribuídas.

Imagina o seguinte:

Caso de Uso 001 wrote:
professor avisa que vai faltar

Pelo que eu estou entendendo do seu ponto de vista (eu posso muito bem não ter entendido nada, ams é o que eu acho), o aluno deveria ter algo assim:

Mas não, pdoe muito bem ser assim:

Isso foi um exemplo idiota, mas o princípio é este: separar responsabilidades.

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

pcalcado,

Isso para mim é uma dura discussão.. Seu exemplo na minha opinião expressa exatamente sua opinião que, como já te falei, não a considero de forma nenhuma incorreta. Só acho que ainda há uma etapada a ser vencida no seu código.

Uma coisa me surgiu na cabeça: Você falou sobre a separação entre a view e a aplicação usando uma camada leve e tal.. Como o Gerenciador do Exemplo. Só que veja bem: Se eu recupero um aluno na view e restauro um estado qualquer neste Aluno, eu posso muito bem, na view, executar o Aluno.save() que, ao meu ver, seria um rompimento desta camada.. Posso estar errado..

Vou colocar alguns trechos sobre este assunto que foi publicado por Fernando Lozano na java magazine (não sei qual sua opinião a respeito desta revista muito menos sobre o autor), mas vale como mais uma opinião:

"Talvez sua dúvida surja de um erro comum na modelagem orientada a objetos - o de modelar classes de informação, por exemplo "Cliente", agregando a elas funcionalidades de negócios. Mas é necessario modelar os próprios processos de negócios, em geral decorrentes dos casos de uso do sistema. As classes que realizam tais processos não têm estado persistente (pois representam atividades sendo realizadas), e são elas que contêm a inteligência de negócios do sistema. Para modelar esses processos adequadamente, em vez de diagramas de classes, procure concentrar-se nos diagramas de atividades (para modelar o processo em si) e os de sequencia/colaboração (permitindo identificar como as classes trabalham juntas para realizar o processo no sistema) (...)

A classe ClienteDTO não deve ser responsável pela sua inclusão, atualização, etc. Nem, digamos, por validar o seu prórpio crédito ou classificar a si mesma como um "cliente vip". Como o conceito de cliente é independente de tecnologias e produtos, por exemplo, de banco de dados, ele deve ser modelado numa classe separada e pode ser utilizado por vários processos de negócios diferentes. Por isso deve estar disponível de forma leve, sem sem criar dependências artificiais entre tais processos. (...)

Coloque agora o cliente em algum contexto, por exemplo, a venda de eletrodomésticos. Aqui o cliente poderia ser utilizado no processo de vendas, junto com dados do produto, nota fiscal, pagamento, condições de entrega, etc. Uma classe de negócios reúne todas as informações necessárias (os dtos correspondentes) e efetiva a operação, provavelmente chamando em sua implementação métodos dos DAOs relacionados e/ou outras classes de negócios.

Pense bem: não faz sentido, conceitualmente, inserir inteligência relativa à realização de uma venda em nenhuma classe de informaçào envolvidas. Será que a classe Nota Fiscal deveria saber como autorizar um pagamento por Cartão de Crédito? Deveria "PagamentoEmCartao" saber que existe uma promoçãoem que a própria loja está financiando o parcelamento sem juros do home theater sem repassar nada ao cliente? Estes dois exemplos ilustram possiveis violações de encapsulamento das classes envolvidas, mas o fato é que alguma classe precisa ter esta inteligência. "

Recomendo realmente a leitura deste artigo. Trata-se de um cara experiente que ilustra o texto com vários exemplos reais.

[]`s

Marco Vinicius

Agradeço a você por proporcionar uma discussão de muito bom nível com uma base forte de conhecimento. Isso nos ajuda a ampliar nossa capacidade de visualização dos problemas e como enfrentá-los de forma inteligente.

Caso tenha interesse na revista, procure adquirí-la no próprio site: Edição 20 - Ano III.

mvcsouza wrote:
Uma coisa me surgiu na cabeça: Você falou sobre a separação entre a view e a aplicação usando uma camada leve e tal.. Como o Gerenciador do Exemplo. Só que veja bem: Se eu recupero um aluno na view e restauro um estado qualquer neste Aluno, eu posso muito bem, na view, executar o Aluno.save() que, ao meu ver, seria um rompimento desta camada.. Posso estar errado..

Você não está rompendo a separação de camadas se não tocar uma camada que nãoe steja ligada, no caso do save(), não há problema.

mvcsouza wrote:
Vou colocar alguns trechos sobre este assunto que foi publicado por Fernando Lozano na java magazine (não sei qual sua opinião a respeito desta revista muito menos sobre o autor), mas vale como mais uma opinião:

Eu sabia que esse artigo ia causar coisas deste tipo

Eu tenho essa revista e estou inclusive escrevendo um post no meu blog sobre isso. Fernando Lozano é sim um cara muito respeitado, mas o que ele afirma não tem fundamento na literatura.

Essa coisa de "antigamente se acahva tal, hoje em dia se acha isso" sem nenhuma referência, sem nenhum motivo (caso seja ele mesmo o autor da teoria), não me parece válido.

Tivemos uma discussão sobre um outro artigo dele aqui, eu o convidei para entrar mas parece que ele não teve tempo de participar.

Eu acho terrivelmente equivocada esta abrodagem e lamento que seja divulgada num veículo tão abrangente como a Java Magazine sem qualquer referência de onde se possa ter mais informação sobre essa teoria.

Segundo o que já li, o futuro da orientação a Objetos é ser Estruturada, com dados de um lado e lógica de outro. Isso não me parece sensato.

Até a próxima então

[]s

JavaEvangelist Membro desde: 07/04/2005 11:37:42 Mensagens: 328 Offline

pCalcado,

Finalmente algum tipo de esclarecimento. Realmente eu estava confuso com este tópico, pois o artigo do Fernando Lozano foi um dos meus primeiros contatos com patterns...

Para mim sempre foi regra que: aluno.save() é ruim!

Agora é hora de considerar melhor a questao.

puxa, eu sei que não é legal colocar objetos totalmente burros em seu sistema, mas deixar os objetos super dotados não me parece muito bom...

microfilo wrote:puxa, eu sei que não é legal colocar objetos totalmente burros em seu sistema, mas deixar os objetos super dotados não me parece muito bom...

O que voce chama de objetos super-dotados?

JavaChild Membro desde: 03/08/2005 15:06:13 Mensagens: 141 Offline

pcalcado wrote:

microfilo wrote:puxa, eu sei que não é legal colocar objetos totalmente burros em seu sistema, mas deixar os objetos super dotados não me parece muito bom...

O que voce chama de objetos super-dotados?

Implicitamente: são objetos com muitos comportamentos.
O que nos leva a uma chamada recursiva nos topicos "programação procedural - objetos burros" , que só pode ser finalizada quando todos souberem que objetos são formados por comportamentos + dados.

Essas tópicos longos com opniões diferentes são o bicho. xD .

Nem sempre é preciso utilizar patterns. Mesmo quando utilizadas, suas patterns não precisam ser identicas ao do autor do livro ou artigo, é preciso saber ser flexivel e toma-las como uma base segura para a sua propria criação. Ou utilizar tim tim por tim tim se ela "te cair como uma luva".

faq wrote:
Implicitamente: são objetos com muitos comportamentos.
O que nos leva a uma chamada recursiva nos topicos "programação procedural - objetos burros" , que só pode ser finalizada quando todos souberem que objetos são formados por comportamentos + dados.

A grande dificuldade que eu vejo nas duvidas comoe sta eh uma soh: separar responsabilidades.

faq wrote:
Nem sempre é preciso utilizar patterns. Mesmo quando utilizadas, suas patterns não precisam ser identicas ao do autor do livro ou artigo, é preciso saber ser flexivel e toma-las como uma base segura para a sua propria criação. Ou utilizar tim tim por tim tim se ela "te cair como uma luva".

O mesmo com paradigmas (como OOP), a questao eh que ate agora, neste ou em tantos outros topicos, ainda nao vi um caso onde realmente fosse rpeciso adaptar os conceitos drasticamente.

JavaChild Membro desde: 03/08/2005 15:06:13 Mensagens: 141 Offline

O mesmo com paradigmas (como OOP), a questao eh que ate agora, neste ou em tantos outros topicos, ainda nao vi um caso onde realmente fosse rpeciso adaptar os conceitos drasticamente.

Por isso são patterns.

carneiro wrote:Para mim sempre foi regra que: aluno.save() é ruim!

Dependendo de como você vai fazer, pode ser bom ou ruim. Eu, por exemplo, implementei o Active Record (o padrão que botaria o "save()" no aluno) com uma única interface (usando AOP) e sem adicionar uma linha de código nas classes do modelo (o Aluno, Turma, Disciplina, Produto ou seja lá o que for).

O que você tem que garantir é que a coisa seja maleável, que seja fácil de dar manutenção e de testar (não ficou tão fácil de testar quanto eu pensava, entretanto...).

Como ja mencionei algumas vezes aqui, ao inves de AR puro e simples, eu prefiro uma abordagem baseada em Observers.

Quando o objeto muda de estado (ou quando recebe um .svae(), mais pratico e usavel) ele avisa seus observadores, o DAO, Repositorio, whatever eh um destes.

This message was edited 4 times. Last update was at 15/08/2005 09:08:40

Rubens wrote:puxa, eu sei que não é legal colocar objetos totalmente burros em seu sistema, mas deixar os objetos super dotados não me parece muito bom...

IMHO, se seu objeto estiver super dotado é pq ele tem responsabilidade demais, e ele entaum poderia ser quebrado em mais classes de negócio. Assim, todos seus objetos se manteriam simples!

Maurício wrote: O que você tem que garantir é que a coisa seja maleável, que seja fácil de dar manutenção e de testar (não ficou tão fácil de testar quanto eu pensava, entretanto...).

Mas pq ficou mais difícil de testar? Por causa do AOP? Ou por causa do ActiveRecord?

Quando eu testo, eu apenas passo um mock para minha classe de negócio, e no final do teste verifico se o método dao.save(aluno) foi realmente chamado e se recebeu o objeto correto por parâmetro.

Entaum, baseado no exemplo acima, apesar de não ser exatamente um AR, acredito que testar um AR não deve ser muito diferente disso!

Estou errado?

Abraços!
Thiago

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