Duvidas sobre modelagem usando ORM
Daniel Sato
Estou acompanhando a algum tempo o grupo e tenho gostado muito. Não tenho tanta experiência quanto os membros desse grupo.
Não tenho muita experiência em Framework de Persistência e por isso estou sentindo muita dificuldade em modelar sistemas dessa maneira.
Nunca usei framework de persistencia em mais de uma ou duas tabelas. Só conheço a seguinte modelagem:
Camada DAL (Persistencia na unha com ADO.NET)
Camada DTO (Somente um esqueleto da classe, só contem propriedades)
Camada BLL (Implementava as regras de negócios e validava antes de enviar para a DAL)
Camada Apresentação (asp.net, winform etc...)
Gosto muito de fazer isso porque a Aplicação cliente nao conhece a DAL (não tem conhecimento sobre o Banco)
A aplicação cliente só conhece a BLL (vantagem que as regras de negócios ficam centralizadas em uma camada separada, podendo assim ser aproveitada em outros tipos de clientes como mobile ou winform)e a DTO que é necessária para instanciar os objetos.
Acho interessante fazer isso porque existe uma unica porta de entrada e saida de dados, que é atraves da BLL, dessa maneira eu obrigatoriamente faço os dados passarem pelas respectivas regras antes de persisti-los.
Minha dúvida surge agora:
Usando o nhibernate eu nao vejo como criar as classes na DTO. e sim somente na DAL. O problema é que a Aplicação cliente nao deve deve conhecer a DAL, e sem conhecer a DAL nao há como instanciar objetos que estao definidos nela. A Aplicação cliente só pode conhecer a DTO e a BLL. Como eu consigo resolver esse problema usando Nhibernate?
Rodrigo Kumpera
e descobriram que era uma enorme perda de tempo. Evite DTOs a não ser que você tenha claramente a necessidade
de usá-los - transferência de dados entre tiers separados fisicamente.
Daniel Sato
Sendo assim terei que criar as classes na DAL, e até onde eu sei terei que expor essa camada para a Aplicação cliente pois a mesma vai precisar instanciar objetos. Dessa forma os metodos de CRUD tambem serão expostos.
Fazendo isso estarei abrindo duas portas de entradas e saídas de dados, através da DAL e da BLL, abrindo a possibilidade para que os dados nao sejam enviados para a BLL.
Daniel Porfirio
Olá Daniel,
Concordo com o Rodrigo...apesar de usar DTO em minha camada de consultas para facilitar a vida da camada de apresentação....mas voltando à vaca fria....vc poderia trabalhar da mesma forma que vc já trabalha a única diferença seria a implementação da sua camada DAL que usaria o NHibernate em vez de DAO .......
--
[]'s.
A Melhor Maneira De Prever o Futuro é Criá-lo.
------------------------------------------------------------------------------------------------------------------------
Daniel da Silva Porfirio
msn: daniel.s...@gmail.com
------------------------------------------------------------------------------------------------------------------------
Acesse http://www.clickarvore.com.br, registre-se e plante uma árvore diariamente!
Nosso planeta agradece.
Daniel Sato
Não discordo de vcs, com certeza vcs têm mais exteriência do que eu sobre modelagem e OO. Eu simplesmente nao consigo visualizar como trabalhar sem a DTO, sem gerar duas possibilidades de entradas e saidas de dados na aplicação cliente (BLL e DAL). Vcs poderiam me mostrar como fazer isso?
Daniel Porfirio
Daniel Sato
Mas fiquei curioso, achei que o uso de DTO era uma otima escolha. Estou tentando definir um padrao a ser usado em um projeto que financeiro que será será implementado em asp.net, windows mobile, e talvez winform. A solução também usará WCF e WWF (dependendo da regra de negocio). Alguém sugere uma arquitetura melhor do que usando DTO?
Outro problema que nao faço idéia de como contornar será a possibilidade de alterar o ORM para entity Framework no caso dele amadurecer em breve. São decisões dificeis de serem tomadas. Se puderem me dar uma mão estou aberto a receber dicas e opiniões.
Rodrigo Kumpera
Obrigado pelo exemplo Daniel e obrigado pela dica Rodrigo
Mas fiquei curioso, achei que o uso de DTO era uma otima escolha. Estou tentando definir um padrao a ser usado em um projeto que financeiro que será será implementado em asp.net, windows mobile, e talvez winform. A solução também usará WCF e WWF (dependendo da regra de negocio). Alguém sugere uma arquitetura melhor do que usando DTO?
Você pode simplesmente expor teus objetos de domínio sem o menor problema. A camada de persistência pode continuar sendo feita usando DAO, ou o novo buzz, Repository.
DTOs tem uso claro e a não ser que teu sistema configure um, é perda de tempo. Só vai contribuir p/ criar uma camada inútil de código que converte entre 2 tipos de objetos a troco de nada.
Sugiro voce ler o Enterprise Patterns do Fowler para entender melhor sobre as decisões que está tomando.
Outro problema que nao faço idéia de como contornar será a possibilidade de alterar o ORM para entity Framework no caso dele amadurecer em breve. São decisões dificeis de serem tomadas. Se puderem me dar uma mão estou aberto a receber dicas e opiniões.
Para que migrar para EF a troco de nada? Ainda mais quando boa parte dos especialistas da indústria dizem o quao desastroso ele é.
André Dias
André Dias
SCJP - SCWCD - MCP - MCTS - CSM
http://blogs.msdn.com/andredias
http://twitter.com/andrediasbr
Phillip Calçado
2009/7/30 André Dias <br.a...@hotmail.com>:
> É que na época do Java, criávamos quantos DTOs "dessem na telha", sem nos
> preocuparmos com o modelo de negócio o que deixava o nosso código bastante
> bagunçado e sem nenhuma estrutura. Aí começaram a dividir o pattern DTO
> (conhecido como VO também) em dois patterns: DTO e Entitites, onde o DTO
> fica direcionado apenas a transferir dados que não estejam relacionados ao
> domínio da sua aplicação (resultados ou filtros de consultas complexas, por
> exemplo RelatorioPagamentoDataHolder) e Entities (que são classes do seu
> negócio, por exemplo, Pessoa, Carro, Produto).
Isso não condiz com a definição do padrão Data Transfer Object ou com
o do padrão Entity. DTOs são utilizados para transferir objetos entre
Camadas *físicas*, não lógicas. Basicamente eles servem como apoio
quando voc6e precisa disponibilizar objetos para algum outro processo,
seja na mesma máquina ou através da rede.
> Aí apareceu um cidadão, colocou tudo isso em uma sacola junto com
> Repository, Services e chamou de DDD. Desde então o DTO ficou feio, assim
> como o WebForms após o lançamento do ASP.NET MVC :-p
Err... não. Domain-Driven Design é apenas uma forma de se pensar sobre
o Domain Model. Ele não fala nada sobre DTOs.
> Na prática tanto DTO quanto Entities são classes com atributos para
> transferir valores, porém fazendo essa divisão, você deixa o seu código mais
> organizado.
Novamente isto não condiz com a descrição do padrão Entity.
Como o Kumpera sugeriu, recomendo a leitura dos livros do Martin
Fowler e Eric Evans.
[]s
--
Phillip Calçado
http://fragmental.tw
http://www.fragmental.com.br
Rodrigo Kumpera
E o que ele quer fazer? Transferência de dados entre camadas!
Camadas físicas ou lógicas? Não faz o menor sentido usar DTO entre camadas lógicas. Além disso, mesmo em camadas físicas, DTO é uma otimização
caso o volume de dados necessários p/ transferir um objeto do modelo for muito grande.
É que na época do Java, criávamos quantos DTOs "dessem na telha", sem nos preocuparmos com o modelo de negócio o que deixava o nosso código bastante bagunçado e sem nenhuma estrutura. Aí começaram a dividir o pattern DTO (conhecido como VO também) em dois patterns: DTO e Entitites, onde o DTO fica direcionado apenas a transferir dados que não estejam relacionados ao domínio da sua aplicação (resultados ou filtros de consultas complexas, por exemplo RelatorioPagamentoDataHolder) e Entities (que são classes do seu negócio, por exemplo, Pessoa, Carro, Produto).Aí apareceu um cidadão, colocou tudo isso em uma sacola junto com Repository, Services e chamou de DDD. Desde então o DTO ficou feio, assim como o WebForms após o lançamento do ASP.NET MVC :-pNa prática tanto DTO quanto Entities são classes com atributos para transferir valores, porém fazendo essa divisão, você deixa o seu código mais organizado.
Um DTO é a mesma coisa que um objeto de domínio se você usar um modelo anêmico.
Daniel Sato
Muito obrigado pelas Opiniões..
rodrigoy
Daniel, você está dizendo que são camadas físicas, você está dizendo
que o Domain Model está rodando em máquinas separadas?
(como o Kumpera falou, nem mesmo entre tiers é obrigatório usar DTOs)
Daniel Sato
rodrigoy
Se não é só uma camada de aplicação diferenciada para o Mobile e o
Domain Model é o mesmo no servidor.
On 29 jul, 13:52, Daniel Sato <danielsa...@gmail.com> wrote:
> Terao de ser camadas fisicas sim, Em asp.net vai ficar tudo no servidor, mas
> para windows mobile nao, eles acessarao o servidor remoto pela internet via
> wcf, logo os mobiles nao terao as class library como a DAL e a BLL.
> Consegui explicar?
>
Daniel Sato
André Dias
> Isso não condiz com a definição do padrão Data Transfer Object ou com
> o do padrão Entity. DTOs são utilizados para transferir objetos entre
> Camadas *físicas*, não lógicas. Basicamente eles servem como apoio
> quando voc6e precisa disponibilizar objetos para algum outro processo,
> seja na mesma máquina ou através da rede.
Vou inventar um novo pattern para facilitar as cosias, o OTDIMT (Objeto para Transferencia de Dados Indepentente do Meio de Transporte). UsuarioOTDIMT u = new UsuarioOTDIMT();
> Err... não. Domain-Driven Design é apenas uma forma de se pensar sobre
> o Domain Model. Ele não fala nada sobre DTOs.
>
>
> Novamente isto não condiz com a descrição do padrão Entity.
>
check out the rest of the Windows Live™. More than mail–Windows Live™ goes way beyond your inbox. More than messages
André Carlucci
--
André Carlucci
Lincoln Granado
[ ]'s
Lincoln
Antonio Pedro
Olha o que o zé da silva diz sobre DTO: http://martinfowler.com/bliki/AnemicDomainModel.html
Antonio Pedro
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
Daniel Porfirio
Alexandre Valente
Rodrigo Kumpera
A única resposta certa é que sem profiling não tem como dizer com certeza. Usar DTO aumenta
o trabalho do desenvolvedor.
Você pode ter dois cenários bem diferentes: em um, a conectividade é lenta, via GPRS, e a empresa vai ser
bilhetada por kb transferido; no outro o acesso é rápido, via wireless, e tem custo efetivo zero. Em um deles
usar DTO faz todo sentido, no outro só para payloads muito grandes.
Enfim, a única coisa que realmente posso dizer que seria errado é usar um modelo remoto com granularidade
fina, usando um proxy local e fazendo montes de chamadas remotas. Cada requisição deve entregar todos dados
para processá-los localmente se voltar ao servidor.
Como isso se encaixa no modelo do WCF eu não sei, pois não conheço a tecnologia.
Daniel Sato
Tudo bem, minha duvida ainda nao foi sanada. Se existe um padrao mais logico e que de menos manutenção gostaria de um exemplo pratico e nada tecnico demais.
Gosto de DTOs, mas nao sou teimoso, se me provarem de maneira pratica que nao usa-lo e de como usar outra coisa seria melhor com certeza me tornaria adpto a esse padrao que para mim é "DESCONHECIDO".
Juliano Oliveira
[]´s
Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira
Daniel Sato
Obrigado pela dica.
Juliano Oliveira
André Dias
caso o volume de dados necessários p/ transferir um objeto do modelo for muito grande."
Indo pra prática e assumindo que teremos apenas camadas lógicas, como você implementaria uma tela de busca de Pessoa (filtro + resultado) sem usar DTO?
"Um DTO é a mesma coisa que um objeto de domínio se você usar um modelo anêmico."
Juliano Oliveira
[]´s
Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira
Antonio Pedro
Por isso mesmo, se em 2003 já se falava em evitar o uso indiscriminado de DTO’s. Quanto mais hoje!!!!
Eu reparei na data do documento e cacei ele no Google para passar justamente esse link.
Também concordo em ser pragmático, o que não concordo é trabalhar como se trabalhava a mil anos atrás com o VB6 e dizer que está trabalhando com Orientação a Objetos.
Att,
Antonio Pedro
Daniel Porfirio
Rodrigo Kumpera
o comportamento do seu modelo está espalhado nas tais business layers.
Rodrigo Kumpera
ano um dos maiores especialistas brasileiros do assunto vai estar no Brasil fazendo workshops sobre o assunto.
Antonio Pedro
Vejam o que o Giovanni postou esses dias no blog dele:
http://unplugged.giggio.net/unplugged/post/Tell-dont-ask.aspx
Att,
Antonio Pedro
De:
dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Rodrigo Kumpera
Enviada em: quarta-feira, 29 de
julho de 2009 16:37
Para:
dotnetar...@googlegroups.com
Assunto: [dotnetarchitects] Re:
Duvidas sobre modelagem usando ORM
Aproveitando, se você está confuso ou se tem vontade de aprender melhor sobre isso, no final do
Daniel Porfirio
Rodrigo Vieira
Rodrigo Kumpera
rodrigoy
comunidade Java a uns 3-4 anos atrás. Os mesmos questionamentos, as
mesmas colocações e a mesma falta de compreensão.
Bem-vindo ao desenvolvimento de software do 3o. milênio. Sim, em
desenvolvimento green-field faz uns bons 4-5 anos que não ligo para o
banco de dados e o hibernate GERA sim tudo para mim. Faz uns bons 4-5
anos que eu não preciso de DBAs (principalmente aqueles que pregam
suas implementações de SQL com se fosse religião, se DBA ainda há
alguma utilidade hoje ele deve ser um DBA multi-banco). Sim, eu
abstraio o Banco de Dados, pois meu desenvolvimento não é orientado a
banco e sim a objetos.
Consultar só fontes da internet para falar sobre Domain-Driven é bem
pouco. E além disso, é lógico que se o seu cliente não está se
importando como são suas entidades, value-objects, serviços e
repositórios é bem provável mesmo que você não está fazendo/
compreendendo Domain-Driven e pode criar os padrões que você quiser.
Domain-Driven não é feito dentro do computador... é feito fora dele.
Para o pessoal DotNet eu recomento o livro Applying Domain-Driven
Design and Patterns do Jimmy Nilsson com exemplos em C#. Leitura
agradável e obrigatória.
Não endendí o porque da agressividade, ninguém aqui está falando nada
de absurdo.
Abraços e sem briga...
Rodrigo Yoshima
ASPERCOM
Phillip Calçado
Eu vejo alguns pontos bem interessantes no seu email mas,
infelizmente, ele está recheado de deboche e eu não respondo este tipo
de mensagem. Se você reescrever suas idéias de uma maneira menos
gratuitamente agressiva e mais argumentativa creio que teremos alguns
pontos interessantes aqui para a discussão.
[]s
2009/7/30 André Dias <br.a...@hotmail.com>:
Phillip Calçado
http://fragmental.tw
http://www.fragmental.com.br
Phillip Calçado
2009/7/30 Alexandre Valente <alexandre...@gmail.com>:
> Este paper é de 2003!!! Muuuuita coisa mudou na indústria de lá pra cá!
> Aliás, é raro um paper em TI que sobreviva mais de 2 ou 3 anos, quanto mais
> técnico, pior! Assim, é importante sempre ver a data em que as coisas foram
> escritas....
Não exatamente. As implementações mudam, os conceitos ficam. Ontem a
noite mesmo eu descobri que Luca Cardelli escreveu um paper em 1992
sobre os tipos dinâmicos que estão sendo implementados em C# só agora,
um exemplo de que idéias "antigas" não ficam defasadas tão
frequentemente assim.
> No caso do Fowler ele mesmo mudou várias vezes de opinião (na época que isto
> foi escrito nem existia DDD! :-)).
Não creio que isto seja relevante mas o Martin cita o trabalho de Eric
Evans no seu livro (pg 325). Eles trabalharam juntos em muitos dos
padrões e quando livro do Evans fi lançado no ano seguinte o Martin
escreveu o prefácio. A critério de curiosidade o artigo do Fowler (de
2003 como você cita) é do mesmo ano em que Eric Evans publicou
Domain-Driven Design.
> Concordo em parte com o André. Se formos usar só a teoria, a nossa vida fica
> muito complicada, um pouco de pragmatismo é fundamental.
Acho que existe um problema de entendimento aqui: isso não é teoria, é
prática. Se você quer ler a teoria pode encontrar diversos papers no
citeseer ou Google Scholar sobre problemas com sistemas distribuídos
orientados a objetos. Pode encontrar propostas de sistemas de tipos,
protocolos de rede e todo tipo de solução mirabolante para o problema
-lembrando que, como citei acima, tipos dinâmicos em linguagens
estáticas eram mirabolantes em 92.
Ou você pode ler mais sobre como as pessoas resolvem o problema na
prática. No mundo real as pessoas usam linguagens como C#, Java, C++ e
protocolos como SOAP, POX, CORBA, Remoting e RMI. No mundo real eles
têm problemas e não podem esperar a tecnologia evoluir para
corrigí-los, precisam de uma solução imediata porque precisam entregar
um projeto. Após resolver o mesmo problema tantas vezes surgiram
catálogos de padrões como os apresentados pelo Fowler e tantos outros.
As soluções apresentadas nestes não só são práticas bem como derivam
de experiência real.
> No nosso caso, os DTOS ficam na camada de apresentação e não são os objetos
> de domínio, pra facilitar serialização. Claro que DTOs só são utilizados
> quando absolutamente necessário (são bem raros os casos, telas de listas com
> muitos joins são exemplos)... Em geral, simples serialização em XML resolve
> 95% dos casos...
O que você cita parece um caso bem típico do uso apropriado de DTOs.
[]s
Phillip Calçado
2009/7/30 Daniel Sato <danie...@gmail.com>:
> Pelo visto vou ter que estudar muito antes de colaborar com esse forum.
> Tudo bem, minha duvida ainda nao foi sanada. Se existe um padrao mais logico
> e que de menos manutenção gostaria de um exemplo pratico e nada tecnico
> demais.
Seu problema é técnico e não-trivial. Como arquitetos creio que
precisamos conhecer os tipos de arquiteturas e padrões mais utilizados
e como eles resolvem os problemas, portanto creio que você vai
precisar sim ler bastante.
> Gosto de DTOs, mas nao sou teimoso, se me provarem de maneira pratica que
> nao usa-lo e de como usar outra coisa seria melhor com certeza me tornaria
> adpto a esse padrao que para mim é "DESCONHECIDO".
Pra trafegar dados entre Camadas Físicas (i.e. processos ou máquinas
diferentes) então DTOs podem ser uma boa solução. Entre Camadas
Lógicas (i.e. Negócios, Apresentação, etc.) geralmente é uma péssima
idéia. Este artigo pode ajudar, apesar de ser focado em java:
http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs
Alexandre Valente
Oi, Alexandre,
2009/7/30 Alexandre Valente <alexandre...@gmail.com>:
> Este paper é de 2003!!! Muuuuita coisa mudou na indústria de lá pra cá!Não exatamente. As implementações mudam, os conceitos ficam. Ontem a
> Aliás, é raro um paper em TI que sobreviva mais de 2 ou 3 anos, quanto mais
> técnico, pior! Assim, é importante sempre ver a data em que as coisas foram
> escritas....
noite mesmo eu descobri que Luca Cardelli escreveu um paper em 1992
sobre os tipos dinâmicos que estão sendo implementados em C# só agora,
um exemplo de que idéias "antigas" não ficam defasadas tão
frequentemente assim.
O que você cita parece um caso bem típico do uso apropriado de DTOs.
> No nosso caso, os DTOS ficam na camada de apresentação e não são os objetos
> de domínio, pra facilitar serialização. Claro que DTOs só são utilizados
> quando absolutamente necessário (são bem raros os casos, telas de listas com
> muitos joins são exemplos)... Em geral, simples serialização em XML resolve
> 95% dos casos...
André Dias
Talvez você não tenha entendido o meu objetivo quando eu citei a abstração
do banco de dados. Eu estava me referindo a algumas discussões que
aconteceram aqui na lista, onde discutimos sobre abstração do banco de
dados, abstração de infra-estrutura durante a execução de testes, abstração
utilizando frameworks de injeção e até mesmo abstração do framework de
abstração, ou seja, ninguém queria se preocupar com infra-estrutura. Pelo
menos foi a mensagem que ficou para mim.
Porém quando entramos na discussão sobre OO, o purismo chega num nível tão
elevado que eu tenho que pensar até no formato da serialização, canais de
comunicação e em todos os detalhes possíveis de infra-estrutura apenas para
saber se devo ou não criar um simples DTO, o que IMHO é completamente
incoerente com a sentença acima, apenas isso.
Sobre os meus comentários sobre os Design Patterns, tem coisa que é
realmente útil, porém a maioria não passa do velho OOP que a gente já usava
antigamente com uma virgula alterada e com nome diferente, e aí fica uma
puta discussão sem sentido discutindo detalhezinho de pattern.
Sobre o desenvolvimento do 3o. milênio, você tem todo o direito de achar que
geração automática do banco a partir do framemork de persistência é a 8a.
maravilha do mundo e tem o direito também de achar que DBA não é necessário.
Porém a minha visão é completamente diferente e eu diria que o DBA
atualmente é mais essencial do que nunca. Deixe-me explicar porque:
Nós passamos os últimos anos construindo sistemas para armazenar dados. Cada
um estruturado de uma forma, utilizando as plataformas mais heterogêneas
possíveis, com fontes de dados espalhadas por diversas áreas, etc. A minha
visão do 3o. milênio é que agora as empresas querem juntar todas essas
informações e tirarem proveito disso, elas querem ser mais dinâmicas, mais
inteligentes, fazer simulações de cenários avaliando o risco, o retorno de
investimento utilizando toda essa base histórica que eles já possuem. Para
isso, precisamos de uma plataforma de dados diferente das que tinhamos anos
atrás e precisamos de profissionais que saibam lidar com tudo isso. É aí que
entra os DBAs.
Tanto a Microsoft quanto a Oracle não param de investir na plataforma de
dados. São ferramentas para facilitar a captura e tranformação dos dados,
sincronizações em tempo real dessas informações, plataformas de BI para
oferecermos cubos para os nossos clientes para que cada pessoa na empresa
possa ver o relatório a sua maneira. Trazendo apenas informações que lhe
interessam no formato que eles querem. O BSC já está deixando de ser
exclusividade do nível executido e passando a ser utilizado por vários
níveis dentro das empresas. São ferramentas de análise, relatórios,
mineração de dados, isso pra falar só em BI. Não vou nem entrar na questão
de governança, consolidação de servidores para redução de custos, etc ...
Quem vai cuidar de tudo isso? Nós? Talvez, porque tem muita coisas de
desenvolvimento nesse meio, mas com certeza, a responsabilidade de toda essa
brincadeira é de um DBA.
Eu posso estar enganado, mas a minha visão do desenvolvimento do terceiro
milênio é um pouco diferente do que fazer CRUDs com geração automática de
banco!
--
André Dias
SCJP - SCWCD - MCP - MCTS - CSM
http://blogs.msdn.com/andredias
http://twitter.com/andrediasbr
--------------------------------------------------
From: "rodrigoy" <rodr...@gmail.com>
Sent: Wednesday, July 29, 2009 7:35 PM
To: ".Net Architects" <dotnetar...@googlegroups.com>
Subject: [dotnetarchitects] Re: Duvidas sobre modelagem usando ORM
André Dias
André Dias
SCJP - SCWCD - MCP - MCTS - CSM
http://blogs.msdn.com/andredias
http://twitter.com/andrediasbr
Emmanuel G. Brandão
Com o NH, EF, etc..., o DBA passa a não mais definir estratégias de acesso aos dados, mas sim a se preocupar com o armazenamento deles, velocidade no acesso, etc...
E quanto ao purismo, essa é uma questão muito complicada, pois já discutimos isso diversas vezes, por exemplo de até onde devemos abstrair. Cada um terá sua opinião e experiência, e por mais que devemos seguir a cartilha (e aqui também terão divergências) em cada caso existe uma solução mais apropriada.
Na palestra de DDD do Giovanni, no DNAD, ele falou sobre DTO para resolver um caso específico no domínio da aplicação que ele desenvolveu durante a apresentação, o código esta disponível no blog dele.
Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net
___________________________________
Ao encaminhar esta mensagem, por favor:
1 - Apague meu endereço eletrônico;
2 - Apague também os endereços dos amigos que receberam juntamente com você a mensagem, antes de enviar;
3 - Encaminhe como Cópia Oculta (Cco ou BCc) aos seus destinatários. Dificulte assim a disseminação de vírus, spams e banners.
Lobo Junior
- Objetos (OO) possuem comportamento e estado, não apenas dados.
- Value Object não é a mesma coisa que DTO
- DTO não morreu, mas simplesmente não são entidades e não servem para a mesma coisa.
--
"Quando você não está feliz, é preciso ser forte para mudar, resistir à tentação do retorno. O fraco não vai a lugar algum."
Ayrton Senna
Rodrigo Brito
Bom dia galera
Estou acompanhando a algum tempo o grupo e tenho gostado muito. Não tenho tanta experiência quanto os membros desse grupo.
Não tenho muita experiência em Framework de Persistência e por isso estou sentindo muita dificuldade em modelar sistemas dessa maneira.
Nunca usei framework de persistencia em mais de uma ou duas tabelas. Só conheço a seguinte modelagem:
Camada DAL (Persistencia na unha com ADO.NET)
Camada DTO (Somente um esqueleto da classe, só contem propriedades)
Camada BLL (Implementava as regras de negócios e validava antes de enviar para a DAL)
Camada Apresentação (asp.net, winform etc...)
Gosto muito de fazer isso porque a Aplicação cliente nao conhece a DAL (não tem conhecimento sobre o Banco)
A aplicação cliente só conhece a BLL (vantagem que as regras de negócios ficam centralizadas em uma camada separada, podendo assim ser aproveitada em outros tipos de clientes como mobile ou winform)e a DTO que é necessária para instanciar os objetos.
Acho interessante fazer isso porque existe uma unica porta de entrada e saida de dados, que é atraves da BLL, dessa maneira eu obrigatoriamente faço os dados passarem pelas respectivas regras antes de persisti-los.
Minha dúvida surge agora:
Usando o nhibernate eu nao vejo como criar as classes na DTO. e sim somente na DAL. O problema é que a Aplicação cliente nao deve deve conhecer a DAL, e sem conhecer a DAL nao há como instanciar objetos que estao definidos nela. A Aplicação cliente só pode conhecer a DTO e a BLL. Como eu consigo resolver esse problema usando Nhibernate?
Condé - Hotmail
Giovanni Bassi
[]'s
Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com
Oi,
2009/7/30 André Dias <br.a...@hotmail.com>:
> É que na época do Java, criávamos quantos DTOs "dessem na telha", sem nos
> preocuparmos com o modelo de negócio o que deixava o nosso código bastante
> bagunçado e sem nenhuma estrutura. Aí começaram a dividir o pattern DTO
> (conhecido como VO também) em dois patterns: DTO e Entitites, onde o DTO
> fica direcionado apenas a transferir dados que não estejam relacionados ao
> domínio da sua aplicação (resultados ou filtros de consultas complexas, por
> exemplo RelatorioPagamentoDataHolder) e Entities (que são classes do seu
> negócio, por exemplo, Pessoa, Carro, Produto).
Isso não condiz com a definição do padrão Data Transfer Object ou com
o do padrão Entity. DTOs são utilizados para transferir objetos entre
Camadas *físicas*, não lógicas. Basicamente eles servem como apoio
quando voc6e precisa disponibilizar objetos para algum outro processo,
seja na mesma máquina ou através da rede.
> Aí apareceu um cidadão, colocou tudo isso em uma sacola junto com
> Repository, Services e chamou de DDD. Desde então o DTO ficou feio, assim
> como o WebForms após o lançamento do ASP.NET MVC :-p
Err... não. Domain-Driven Design é apenas uma forma de se pensar sobre
o Domain Model. Ele não fala nada sobre DTOs.
> Na prática tanto DTO quanto Entities são classes com atributos para
> transferir valores, porém fazendo essa divisão, você deixa o seu código mais
> organizado.
Novamente isto não condiz com a descrição do padrão Entity.
Como o Kumpera sugeriu, recomendo a leitura dos livros do Martin
Fowler e Eric Evans.
Giovanni Bassi
Na verdade, quase todo mundo usa errado. Geralmente a entidade é representada como uma classe com comportamento, e que expõe propriedades (getters e setters) públicos para todo o estado. Essa idéia de que o estado tem que estar disponível através de propriedades é um anti-pattern, mas tentar explicar de outro jeito complica ainda mais a explicação do conceito. Mas é um fato: uma entidade não deve ter propriedades.
> Isso não condiz com a definição do padrão Data Transfer Object ou com
> o do padrão Entity. DTOs são utilizados para transferir objetos entre
> Camadas *físicas*, não lógicas. Basicamente eles servem como apoio
> quando voc6e precisa disponibilizar objetos para algum outro processo,
> seja na mesma máquina ou através da rede.
Fala sério! anda uma discussão absurda aqui na lista a respeito de abstração. Bye bye DBA, não quero mais saber detalhes do banco pois o NHibernate gera tudo pra mim, Mocks para abstrair detalhes da infra, frameworks para abstrair o abstrato, mas na hora de desenhar uma simples classe eu tenho que me preocupar se ela será serializada ou não, se a comunicação será in-proc ou não? E se eu decidir distribuir o meu sistema, eu o refaço inteiro?? (Ahhhh, tem a primeira regra do zé da silva sobre distribuir software, não distribua!).. Bla bla bla!!!
Vou inventar um novo pattern para facilitar as cosias, o OTDIMT (Objeto para Transferencia de Dados Indepentente do Meio de Transporte). UsuarioOTDIMT u = new UsuarioOTDIMT();
> Err... não. Domain-Driven Design é apenas uma forma de se pensar sobre
> o Domain Model. Ele não fala nada sobre DTOs.
>
As fontes que eu consultei falam, http://en.wikipedia.org/wiki/Domain-driven_design, http://www.domaindrivendesign.org/ .. Ahhh, mas as definições estão diferentes do Sr. de Todos os Poderes da OO. E ??? Se eu uso DTO ou não, estou deixando de fazer DDD da forma mais pura? Ahhh, meu cliente tá tão preocupado com isso, vc não tem idéia.
>
> Novamente isto não condiz com a descrição do padrão Entity.
>
Giovanni Bassi
A questão é que esse problema não se resolve assim tão facilmente. A arquitetura que você está propondo é simples, mas traz diversos problemas. Sinto em dizer, mas não vai ser com um gráfico que você vai solucionar seu problema.
Posso sugerir algumas arquiteturas de referência interessantes. Só que sem o embasamento elas vão soar complexas demais, verbosas demais.
De qualquer forma seguem alguns exemplos:
Porte da aplicação de exemplo do domaindrivendesign.org
http://code.google.com/p/ndddsample/
Excelente aplicação com conceitos de DI, repositório, etc.
http://code.google.com/p/codecampserver/
Pelo visto vou ter que estudar muito antes de colaborar com esse forum.
Tudo bem, minha duvida ainda nao foi sanada. Se existe um padrao mais logico e que de menos manutenção gostaria de um exemplo pratico e nada tecnico demais.
Giovanni Bassi
Você pode ter um modelo feito com Entity Framework v3.5, que não trabalha com POCO, e ele pode ser anêmico ou não.
E você pode ter um modelo feito com NH, que suporta POCO, que também pode ser anêmico ou não.
Giovanni Bassi
http://video.google.com/videoplay?docid=-7056786168177403020&hl=en
Giovanni Bassi
Assumindo que você está se referindo a DTOs como VOs, e não seguindo escola "martinfowleriana"... e na boa, em geral pouca diferença faz... sigo nesse sentido para evitar confusão...
Assumindo que quando diz "camadas físicas" está se referindo a uma barreira de máquinas, como uma mensagem a um web service, ou talvez entre processos...
Porque você acha que não vale a pena usar DTOs entre camadas lógicas? Entidades não atendem às necessidades de exibição na interface gráfica de maneira eficiente na maioria dos casos; DTOs resolvem o problema. É o tipo caso do contexto de exibição e do contexto transacional, absolutamente diferentes. E na prática, mesmo no contexto transacional, para enviar as mensagens de negócio às entidades, nada mais prático do que objetos de valor, mesmo se estivermos na mesma camada lógica, evitando o anti-pattern de propriedades públicas. O que você acha?
Giovanni Bassi
Aí entra tell don't ask. Em vez de pedir pelos itens da lista e incluir um item, você diz à classe de NF que quer incluir um item e ela que se vire pra fazer isso. Desta forma estamos aplicando a mecânica da OO (encapsulamento) mas atingindo seu objetivo real (abstrair e proteger o dado, funcionar como um objeto do mundo real, etc), o que de fato não acontece da outra forma.
Giovanni Bassi
Não faça conversões um pra um de entidades para DTOs.
No contexto de exibição, o DTO deve mapear para a tela. Ele pode conter info de várias entidades, inclusive transformadas, agrupadas, ordenadas, paginadas, etc...
No contexto transacional, o DTO é uma mensagem de negócio. Ele pode mapear para uma ação que afeta diversas entidades.
Phillip Calçado
2009/7/30 Giovanni Bassi <gig...@giggio.net>:
> Assumindo que você está se referindo a DTOs como VOs, e não seguindo escola
> "martinfowleriana"... e na boa, em geral pouca diferença faz... sigo nesse
> sentido para evitar confusão...
Eu não sei o que você quer dizer por VO neste contexto. VO pode
significar tanto Value Object como catalogado por Fowler e Evans ou o
antigo nome para o que é chamado de Transfer Object desde a segunda
edição do Core J2EE Patterns da Sun. Como alguém citou anteriormente o
Fowler explica no seu livro que o ele chama de VO não é o mesmo que a
Sun chama de VO, logo acho que seguindo uma visão diferente da dele
você quer dizer que está assumindo que VO=DTO. Raciocínio correto?
> Assumindo que quando diz "camadas físicas" está se referindo a uma barreira
> de máquinas, como uma mensagem a um web service, ou talvez entre
> processos...
> Porque você acha que não vale a pena usar DTOs entre camadas lógicas?
DTOs são uma necessidade apenas em virtude da dificuldade existente em
realizar comunicação entre dois espaços de endereçamento fisicamente
isolados (dois processos, máquinas virtuais, servidores, sistemas...).
Num cenário como este você deve ter em mente que chamadas remotas
custam caro e por isso convem ao invés de enviar objetos de
granularidade baixa (objetos de domínio) você empacota objetos em
unidades de granularidade maior (DTOs). Isso minimiza chamadas remotas
e, geralmente, melhora performance e testabilidade.
Mas este padrão não é algo bom, ele foi criado após tantas falhas com
sistemas OO distribuídos. Num mundo ideal não teríamos penalidade
alguma em fazer um objeto no servidor A falar com outro no servidor B
e DTOs não seriam necessários. E por que eles são ruins? Porque vão
exigir lógica para mapear objetos para DTOs, mapear DTOs para objetos
e criam estruturas paralelas de classes, o que significa que você vai
ter código repetido (o diagrama do site do Fowler mostra um exemplo).
Se você está trocando objetos entre duas Camadas (lógicas) dentro do
mesmo processo não há motivo para pagar este preço em termos de
complexidade. Use seus objetos de domínio, nada de criar classes
artificiais, que não pertencem ao domínio e à Ubiquitous Language.
> Entidades não atendem às necessidades de exibição na interface gráfica de
> maneira eficiente na maioria dos casos;
>DTOs resolvem o problema. É o tipo
> caso do contexto de exibição e do contexto transacional, absolutamente
> diferentes. E na prática, mesmo no contexto transacional, para enviar as
> mensagens de negócio às entidades, nada mais prático do que objetos de
> valor, mesmo se estivermos na mesma camada lógica, evitando o anti-pattern
> de propriedades públicas. O que você acha?
Na minha experiência é muito incomum que sua interface não possua um
mapemento para objetos de negócio. Dado que a interface geralmente
reflete a visão do cliente sobre o sistema e que seu domínio, segundo
os princípios de Domain-Driven Design, também deve refletir esta visão
do cliente eu entendo que se não existe um mapeamento próximo de
1-para-1 entre interface e domínio existe um problema de modelagem em
um ou em outro.
É claro que isto não é uma regra. Algumas vezes o domínio é mais
abrangente do que a visão de uma ou outra aplicação, ou existem
objetos que fazem parte do processo de negócio gerenciado pela
aplicação mas não fazem parte do domínio em si. Neste caso geralmente
a sugestão é utilizar mais um dos padrões catalogados pelo Fowler, o
Presentation Model. ë o que usamos, por exemplo, para gerar relatórios
que não possuem um mapeamento com entidades do Domain Model.
Uma boa leitura sobre este tema em específico é o livro de Meilir
Page-Jones sobre UML. Ele aborda estas "camadas de domínio" de uma
maneira bem clara.
Giovanni Bassi
Agora imagine um grid de NFs:
Número da NF | Data de emissão | Emissor da NF | Total de Itens
Nesse cenário tenho dados de três entidades: a NF, o item, e o emissor. Nesse caso tenho um grid que se mapeia para as 3. Ok, posso puxar a entidade NF, e ela vai carregar junto uma associação para os itens e para o emissor. Só que para isso tenho:
- Que fazer um select da NF inteira (mesmo que precise só do número e da data de emissão)
- Que fazer um select em todos os itens da NF (só para pegar o count)
- Que fazer um select em todo o usuário só para exibir um nome
- Fazer um select de dois campos da NF, um count dos itens com join na NF, e um select no nome do emissor com join na NF.
Nesse cenário, nada melhor que um DTO/VO/Presentation Model (ou ViewModel com chamam alguns).
Esse tipo de caso acontece por toda a aplicação. É algo extremamente comum...
Por isso que eu falei que contexto de exibição nunca mapeia para entidade. Dessa forma também evito o anti-pattern de propriedades (getters/setters) públicos.
Phillip Calçado
2009/7/30 Giovanni Bassi <gig...@giggio.net>:
> Nesse cenário, nada melhor que um DTO/VO/Presentation Model (ou ViewModel
> com chamam alguns).
Discordo. Neste caso o que você precisa de de um ORM decente, eu
sugiro o NHibernate. Com lazy loading e consultas em HQL você pode
deixar o framework tomar conta e utilizar seus objetos de negócio
normalmente. No seu caso em específico me parece claro que
NotaFiscal.NumeroDeItens() é um método que, quando chamado, pode
perguntar ao repositório de itens quantos estão associados com a nota
em específico.
Mas no geral em todos estes anos utilizando ORMs (Hibernate,
NHibernate e outros) eu poucas vezes vi o caso onde Lazy Loading
causou algum problema real e mesmo estes casos foram apenas em
aplicações que ou lidam com um volume muito grande de dados ou possuem
requisitos de performance e/ou escalabilidade fora do
feijão-com-arroz. Neste caso eu utilizaria a solução que mencionei
acima, do método na NF que retorna o número de itens.
Ainda que não pudesse não justifica utilizar um "objeto especialista"
(para tentar evitar repetir DTO/Presentation Model/etc. em todo
lugar). Antes da versão 2 do Hibernate (versão Java) praticamente não
existiam ORMs decentes e fazíamos tudo com SQL escrito manualmente. O
que você vai precisar é de um DAO que saiba popular objetos baseados
em resultsets parciais, é muito mais trabalhoso de fazer do que usar
um ORM de verdade mas funciona bem.
> Dessa forma também evito o anti-pattern de propriedades (getters/setters)
> públicos.
Criando objetos especialistas você evita criar propriedades mas acaba
criando um problema muito pior. Pense bem, o grande ponto em não expor
propriedades é exatamente de não deixar detalhes sobre como o objeto X
gerencia seu estado vazarem para objetos que não deveriam depender
destes detalhes e sim da interface publicada pelo objeto.
No seu exemplo não se expõe o estado no objeto em si mas acaba-se
fazendo com que outros estes objetos especialistas conheçam detalhes
sobre como o estado deste objeto de domínio é persistido em banco de
dados. Neste caso o acesso ao estado do objeto persistido é
completamente exposto, nem mesmo a fina barreira que propriedades ou
get/set criam estaria lá para proteger detalhes de implementação.
É como se num assalto você não desse o dinheiro da sua carteira para o
ladrão mas deixasse ele sair com seu cartão do banco e a senha da sua
conta.
For que existe ainda o problema da explosão de objetos especialistas.
Se para cada tipo de operação você precisa de um objeto especialista
diferente é bem provável que no fim seu sistema possua dezenas deles.
E lembre-se que estes objetos não só possuem lógica duplicada dos
objetos de negócio bem como vão possuir lógica duplicada entre eles
mesmos.
Recentemente eu fui chamado para fazer uma análise arquitetural num
sistema de médio porte que seguia este modelo e não fiquei surpreso
quando verifiquei que o volume total de código duplicado era de 40%.
Daniel Sato
Phillip Calçado
2009/7/30 Daniel Sato <danie...@gmail.com>:
> Posso estar enganado, mas Fowler diz aqui:
> http://martinfowler.com/eaaCatalog/dataTransferObject.html que DTO é uma boa
> opção de transporte de objetos em acessos remotos. Entendi bem? foi isso o
> que ele quiz dizer?
Sim, Camdas Físicas geralmente significam acesso remoto (apesar de
também poder ser utilizado para IPC).
Passei os olhos pela documentação do Patterns & Practices e ela me
pareceu bem coerente:
http://msdn.microsoft.com/en-us/library/ms978717.aspx
Tomamais
"A melhor ferramenta é aquela que você conhece"
E olha que nem era de TI! Bom, quanto ao camarada autor da dúvida (até
ler todo o post acabei perdendo o nome dele =P), caso este seja seu
primeiro ou um dos primeiros contatos com um projeto OO que usará ORM,
sugiro que o faça no seu antigo conceito de DTO, DAL, BLL, etc.
Segundo o que descreveu, o projeto é bem crítico e não recomendo
arriscar alguma coisa nova com ele.
Além do mais, entendo que a modelagem do projeto está muito atrelada
em como o aplicativo será construído. Até as perguntas são um pouco
diferentes.
Se seu levantamento levou a uma especificação que lhe dá suporte a
modelagem baseada em DTO, use-o. O problema de usar ORM é que além de
ter que lhidar com outros frameworks, será preciso quebrar alguns
paradigmas. As palestras do Giovanni sobre DDD explicam bem isso.
Finalmente, recomendo que experimente um projeto com ORM menos
crítico. Se gostar, encare um projeto maior. Se este já for o caso, vá
em frente! Minha experiência provou que criar sistemas baseados em
Domínio de Objetos e ORM são melhores de construir, entender e fazer.
A pouco tempo tive que voltar a fazer sistemas baseados em DTO ou em
Bancos de Dados. Depois disso, a coisa só ficou mais envidente.
Abraços
Tomás
www.tomasvasquez.com.br
www.tomasvasquez.com.br/blog
On 30 jul, 03:05, Giovanni Bassi <gig...@giggio.net> wrote:
> Falando do Entity:
> Na verdade, quase todo mundo usa errado. Geralmente a entidade é
> representada como uma classe com comportamento, e que expõe propriedades
> (getters e setters) públicos para todo o estado. Essa idéia de que o estado
> tem que estar disponível através de propriedades é um anti-pattern, mas
> tentar explicar de outro jeito complica ainda mais a explicação do conceito.
> Mas é um fato: uma entidade não deve ter propriedades.
>
> []'s
>
> Giovanni Bassi
> Microsoft MVP, MCSD, MCPD, CSM
> Arquiteto de softwarehttp://www.giovannibassi.com
>
>
>
> > > Isso não condiz com a definição do padrão Data Transfer Object ou com
> > > o do padrão Entity. DTOs são utilizados para transferir objetos entre
> > > Camadas *físicas*, não lógicas. Basicamente eles servem como apoio
> > > quando voc6e precisa disponibilizar objetos para algum outro processo,
> > > seja na mesma máquina ou através da rede.
>
> > Fala sério! anda uma discussão absurda aqui na lista a respeito de
> > abstração. Bye bye DBA, não quero mais saber detalhes do banco pois o
> > NHibernate gera tudo pra mim, Mocks para abstrair detalhes da infra,
> > frameworks para abstrair o abstrato, mas na hora de desenhar uma simples
> > classe eu tenho que me preocupar se ela será serializada ou não, se a
> > comunicação será in-proc ou não? E se eu decidir distribuir o meu sistema,
> > eu o refaço inteiro?? (Ahhhh, tem a primeira regra do zé da silva sobre
> > distribuir software, não distribua!).. Bla bla bla!!!
>
> > Vou inventar um novo pattern para facilitar as cosias, o OTDIMT (Objeto
> > para Transferencia de Dados Indepentente do Meio de Transporte).
> > UsuarioOTDIMT u = new UsuarioOTDIMT();
>
> > > Err... não. Domain-Driven Design é apenas uma forma de se pensar sobre
> > > o Domain Model. Ele não fala nada sobre DTOs.
>
> > As fontes que eu consultei falam,
> >http://en.wikipedia.org/wiki/Domain-driven_design,
> > estou deixando de fazer DDD da forma mais pura? Ahhh, meu cliente tá tão
> > preocupado com isso, vc não tem idéia.
>
> > > Novamente isto não condiz com a descrição do padrão Entity.
>
> > É verdade, esqueci de colocar duas virgulas que estavam na biblia sagrada
> > do padrão Entity.
>
Giovanni Bassi
Apesar de você poder chamar um Repositório em uma entidade, eu não gosto quando isso é feito. E mesmo que fizessemos isso, eu teria uma consulta ineficiente, com 3 consultas sendo feitas neste exemplo (uma de NF, uma de count de NF, e uma de usuário). Indo além disso, não sei se é responsabilidade da NF chamar o repositório, ou se preocupar com a quantidade de itens, que é uma preocupação apenas da interface gráfica.
O Single Responsability Principle é um dos principais motivos para trabalhar com objetos especialistas. Entidades de domínio não se encaixam nas preocupações da interface gráfica, e se tivéssemos que adaptá-las para isso, quebramos o SRP, já que elas passariam a ter 2 motivos para mudar.
Sou a favor de um design com mais classes, que cooperam entre si. Há duplicação de código? Não, há duplicação de conceitos. Por exemplo, no viewmodel de exibição você teria o número da NF, e na entidade NF também, mas não é necessariamente o mesmo código, na de exibição este número pode estar formatado, por exemplo. E várias outras propriedades da entidade não fazem parte da classe de viewmodel.
Já sofri bastante em tentar reutilizar contextos transacionais para exibição. Eventualmente você acaba tendo problemas. E é ineficiente. Mas entendo que alguém siga nesse caminho, só não acho o ideal.
Daniel Sato
Fui eu que levantei a dúvida nesse post. O pessoal aqui me falou de muitas possibilidades e padrões,
nao entendi a maioria deles. Dei uma olhada no mapper que o Juliano me passou e pelo
que entendi o mapper é simplesmente um framework que libera o desenvolvedor de
fazer a DTO, mas o funcionamente é o mesmo. Tenho q estudar mais sobre isso,
mas no momento só me sinto seguro usando DTO mesmo, pois nao consegui ver
outra maneira de expor os objetos sem expor a DAL ou DAO. O pessoal aqui falou de várias padrões
mas nao consegui ver a praticidade de muitos deles.
Daniel Sato - Analista e Consultor.
edmilson hora
Pessoal,
Eu tenho a mesma dúvida que o Daniel postou, so utilizo esse padrão DTO / DAL /BLL / App.
Li todas as respostas deste post até agora e continuo com a mesma dúvida. Tem algum padrão que o pessoal utiliza em seu projetos no dia-a-dia nas empresas que trabalham que é diferente do padrão citado no post inicial do Daniel? Se Sim, por gentileza, compartilhem esta informação, acredito que muita gente aqui do grupo gostaria de conhecer padrões mais eficientes e com melhor manutenção. Mas sem utilizer ORM, Ok?
[]´s
Edmilson
|
|
|
Phillip Calçado
2009/7/31 Giovanni Bassi <gig...@giggio.net>:
> Apesar de você poder chamar um Repositório em uma entidade, eu não gosto
> quando isso é feito. E mesmo que fizessemos isso, eu teria uma consulta
> ineficiente, com 3 consultas sendo feitas neste exemplo (uma de NF, uma de
> count de NF, e uma de usuário).
Acho que você já ouviu dizer que "otimização prematura é a raiz de
todo o mal", não? Tud em arquitetura de software é uma questão de
valorizar o que é importante no contexto específico. Se você for
pensar apenas na solução mais eficiente do ponto de vista de
performance nunca vai usar um ORM. Ou Camadas. Ou MVC. Ou mesmo código
gerenciado.
Ms, como falei antes, caso isso fosse um problema real e você tivesse
números para constatar otimização seria apenas o caso de escrever uma
consulta específica usado SQL ou HQL. Você não precisa criar objetos
especialistas só por causa disso.
Eu já trabalhei em alguns sistems com requerimentos de performance bem
extremos -billing de celular pré-pago, portais de internet, sistema de
análise de risco para mercado financeiro, etc.- e nunca tive problemas
com isso.
> Indo além disso, não sei se é
> responsabilidade da NF chamar o repositório, ou se preocupar com a
> quantidade de itens, que é uma preocupação apenas da interface gráfica.
Como falei antes, na maoria dos cenários tanto a interface gráfica
quanto o domínio representam a visão do usuário (ou especiaista no
domínio) sobre o problema e solução. Se este não é o caso ou este
sistema é peculiar ou existe algum problema de modelagem em algum dos
dois.
> O Single Responsability Principle é um dos principais motivos para trabalhar
> com objetos especialistas. Entidades de domínio não se encaixam nas
> preocupações da interface gráfica, e se tivéssemos que adaptá-las para isso,
> quebramos o SRP, já que elas passariam a ter 2 motivos para mudar.
Se estivéssemos falado de, por exempo, como uma data é apresentada
(DD/MM/AAA versus MM/AA, por exemplo) eu concordaria mas neste caso o
item mencionado é apenas uma propriedade do objeto de domínio.
> Sou a favor de um design com mais classes, que cooperam entre si. Há
> duplicação de código? Não, há duplicação de conceitos. Por exemplo, no
> viewmodel de exibição você teria o número da NF, e na entidade NF também,
> mas não é necessariamente o mesmo código, na de exibição este número pode
> estar formatado, por exemplo. E várias outras propriedades da entidade não
> fazem parte da classe de viewmodel.
Um bomd esign sempre vai ter classes que colaboram entre si mas isso
nã quer dizer que classes especialistas sejam boas, do contrário todos
os métodos seriam implementados como Commands.
Duplicação não é apenas CTRL-C CTRL-V, duplicação de código é quando
você tem duas partes no sistema que fazem a mesma coisa.Neste caso
ambos modelam o mesmo conceito. Se o conceito de NF fiscal mudar, se
você remover um atributo ou mudar a lógica de serialização, vai ter
que mudar em mais de um lugar. Isso é lógica duplicada e indica um
alto acoplamento entre estas classes.
Meu ponto se resume a: exceto em raros casos, ao utilizar esta
arquitetura você vai (1)criar várias classes desnecessárias -já que
poderia usar a classe que já possui, (2) criar um acomplamento muito
grande entre estas classes e o objeto de domínio -representado pelo
fato de que ambos modelam o mesmo conceito e as mesmas tabelas
ecompletamente sem necessidade.
Note que não teho nada contra -apesa de raramente ser realmente úti-
criar um Presentation Model mas este não deveria seguir um caminho
paralelo ao Domain Mode, o PM é apenas um mapeamento do Domain Model.
Phillip Calçado
2009/7/31 edmilson hora <edmils...@yahoo.com.br>:
> Li todas as respostas deste post até agora e continuo com a mesma dúvida.
> Tem algum padrão que o pessoal utiliza em seu projetos no dia-a-dia nas
> empresas que trabalham que é diferente do padrão citado no post inicial do
> Daniel? Se Sim, por gentileza, compartilhem esta informação, acredito
> que muita gente aqui do grupo gostaria de conhecer padrões mais
> eficientes e com melhor manutenção. Mas sem utilizer ORM, Ok?
Sim. um Domain Model com um DAO escrito manualmente. Para mais dtalhes
consulte o livro do Fowler.
Luiz Carlos Faria
Existem diversas abordagens, dependendo da forma como usa aplicação/serviço é modelado ele pode ter responsabilidades diferentes. Vamos aos exemplos:
Em ma aplicação que usa DDD, um DTO é perfeitamente utilizado para representar o que seria o MODEL do MVC. Seria uma representação dos dados com foco em apresentação, enquanto seu modelo de domínio seria robusto e poderia estar em um servidor de aplicação, por exemplo, servindo a toda a empresa. Neste exemplo, o DTO tem características específicas da interface.
Em um modelo mais próximo de um Row Data Gateway você teria um DTO semelhante ao seu banco, e dependendo da abordagem poderia trabalhar com table model (objetos semelhantes às linhas) ou algo mais complexo com mapeamento para outros objetos deste modelo.
Enfim, é apenas uma estrutura de dados utilizada para trafegar conteúdo por duas camadas. Quais camadas? Depende...
De:
dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em
nome de Daniel Sato
Enviada em: quinta-feira, 30 de julho de 2009 08:58
Para: dotnetar...@googlegroups.com
Assunto: [dotnetarchitects] Re: Duvidas sobre modelagem usando ORM
Posso estar enganado, mas Fowler diz aqui: http://martinfowler.com/eaaCatalog/dataTransferObject.html que DTO é uma boa opção de transporte de objetos em acessos remotos. Entendi bem? foi isso o que ele quiz dizer?
Giovanni Bassi
Giovanni Bassi
Phillip Calçado
2009/7/31 Giovanni Bassi <gig...@giggio.net>:
> Como eu disse antes: entendo que um presentation model não tem nada a ver
> com o modelo de domínio, e não há qualquer mapeamento para ele. Apresentação
> trabalha com conceitos absolutamente diferentes do que uma modelagem do
> mundo real precisa lidar.
Isso me parece bem diferente do padrão Presentation Model:
"Presentation Model pulls the state and behavior of the view out into
a model class that is part of the presentation. The Presentation Model
coordinates with the domain layer and provides an interface to the
view that minimizes decision making in the view. The view either
stores all its state in the Presentation Model or synchonizes its
state with Presentation Model frequently
Presentation Model may interact with several domain objects, but
Presentation Model is not a GUI friendly facade to a specific domain
object. Instead it is easier to consider Presentation Model as an
abstract of the view that is not dependent on a specific GUI
framework. While several views can utilize the same Presentation
Model, each view should require only one Presentation Model. In the
case of composition a Presentation Model may contain one or many child
Presentation Model instances, but each child control will also have
only one Presentation Model."
http://martinfowler.com/eaaDev/PresentationModel.html
> Concordo que temos que otimizar o mais tarde possível. Mas da mesma forma,
> eu posso não otimizar nada, e sair sem um ORM em um projeto complexo. Mas
> porque eu faria isso, já que sei que vou precisar de um, já que já dezenas
> de projetos parecidos, e sei o quanto isso é útil?
Porque, como falei antes, arquitetura é baseada em tradeoffs. Se
performance e eficiência são mais importantes que ausência de lógica
duplicada e facilidade de manutenção (e eu já trabalhei em muitos
projetos onde este era o caso) então a otimização faz sentido.
No enunciado do seu exemplo eu não lembro de ler nada relacionado ao
fato de eficiência algoritmica ser mais importante que qualquer outra
coisa.
> Por fim, a questão do SRP ainda pesa demais. Entidades não devem ser
> alteradas para acomodar necessidades da visão.
Não entendo porque SRP seria um problema em utilizar objetos de
domínio. O objeto NF tem apenas um motivo para mudar: se a nota fiscal
mudar. Se você resolver apresentar o número de itens em numerais
romanos ou vermelho-sangue isso não vai afetar a NF.
O efeito contrário é visto com o uso de objetos especialistas. Se uma
NF mudar então você vai ter que mudar seus especialistas.
Giovanni Bassi
Lincoln Granado
[ ]'s
Lincoln
Tomamais
Se ainda se sente confortável com seu modelo em DTO, provavelmente é
porque ainda existem muitos paradigmas a serem quebrados.
A modelagem OO, que entendo ser uma consequência do bom uso de um ORM,
DDD e outros princípios que estão "rolando" neste tópico, é algo que
gosto de chamar de modelagem natural. A OO desde o princípio tem esse
objetivo, pouco entendido até hoje pelo que posso ver. Quando você
modelo o mundo baseado em objetos, você passa a ter uma representação
baseada em objetos muito fiel ao mundo real, chegando a um ponto que,
é tão natural falar das classes criadas como é natural falar do mundo
real.
Esse é o cálice sagrado a ser alcançado quando se faz esse tipo de
modelagem. E quando a equipe entende que isso acontece, passam a
gostar do trabalho pois eles estão entendendo o que está acontecendo,
o que o sistema está fazendo.
Entendo que técnicas como o DTO ou qualquer coisa que seja sacrificada
pela tecnologia, geralmente o banco de dados, viola e quebra essa
modelagem, essa idéia, e passa a sacrificar o entendimento pois você
passa a fazer associações do que é isto ou aquilo. O que existe no
sistema é algo que não existe no mundo real, mas sim representações, o
que não é natural.
Pensar natural é a melhor forma de fazer alguma coisa. Não há ser
humano que não possa achar isso. Mas caso o pensamento já tenha ganho
uma outra forma de fazer determinada coisa, deixou de ser o natural
para ser uma interpretação.
Entendo dessa forma. Minha experiência é pouca, mas suficiente para
ter encarado projetos com diferentes abordagens. A que mais me agradou
e a colegas com quem participei nos projetos, foi a que estamos
discutindo agora.
Mas negócio é negócio. Faça o que for melhor para o projeto no seu
contexto, como sugeri na mensagem anterior. Seu chefe não vai querer
saber se o projeto é feito em DDD ou DTO se ele atrasar certo?
Espero não ter viajado muito.
Abraços
Tomás
www.tomasvasquez.com.br
www.tomasvasquez.com.br/blog
On 30 jul, 15:01, Daniel Sato <danielsa...@gmail.com> wrote:
> Boa Tarde Tomás
>
> Fui eu que levantei a dúvida nesse post. O pessoal aqui me falou de muitas
> possibilidades e padrões,
> nao entendi a maioria deles. Dei uma olhada no mapper que o Juliano me
> passou e pelo
> que entendi o mapper é simplesmente um framework que libera o desenvolvedor
> de
> fazer a DTO, mas o funcionamente é o mesmo. Tenho q estudar mais sobre isso,
>
> mas no momento só me sinto seguro usando DTO mesmo, pois nao consegui ver
> outra maneira de expor os objetos sem expor a DAL ou DAO. O pessoal aqui
> falou de várias padrões
> mas nao consegui ver a praticidade de muitos deles.
>
> Daniel Sato - Analista e Consultor.
>
>
> - Mostrar texto das mensagens anteriores -
Giovanni Bassi
http://martinfowler.com/eaaDev/index.html
Phillip Calçado
2009/7/31 Giovanni Bassi <gig...@giggio.net>:
> A descrição do Fowler só fortalece o que eu disse: PM nada tem a ver com o
> domínio. O domínio modela o mundo real. O PM modela telas.
Não creio que eu tenha dito em lugar algum que PM modela o mundo real.
De qualquer maneira, chamo atenção para este trecho:
"Presentation Model may interact with several domain objects, but
Presentation Model is not a GUI friendly facade to a specific domain
object."
E para o fato de que o PM segundo o texto é criado baseado nos objetos
do domínio e não uma estrutura paralela de ponta a ponta. Digamos que
você tem um motivo para usar um PM, o fluxo seria algo como:
banco de dados -> camada de persistência -> objetos de domínio ->
mapeadores -> presentation model -> view
Meu ponto neste aspecto é apenas contra o uso do nome "presentation
model". Para mim o que você descreve é bem diferente de um, é um
modelo paralelo para consulta (parecido com o que o Greg Young
divulga).
> Acabei esquecendo de comentar o que você havia falado antes de commands.
> Sim, de fato eu acredito que a melhor maneira de se comunicar com um objeto
> de domínio é com commands. Melhor do que pedir ao objeto seu estado e
> alterá-lo, melhor dizer a ele o que deve ser feito com commands, que
> interagem diretamente com o objeto.
Não entendi, você usa Commands para atualizar seus objetos? Acho que
nós estamos usando o termo Command para indicar coisas diferentes, eu
estou falando do Design Pattern da GoF. E não entendo qual a relação
entre este padrão é "objetos burros" neste contexto.
> Você insiste em dizer que há duplicidade, quando de fato não há. Você
> considera que o modelo de domínio é algo que pode ser diretamente ligado à
> interface gráfica. Eu discordo disso. Dessa forma, entendo que as entidades
> possuem estado que classes de exibição não possuem, e vice-versa. Ok, elas
> possuem algum estado em comum, mas e daí? Eles mudam por motivos diferentes,
> eu posso precisar exibir algo novo, que vem de outra entidade (assim como o
> Fowler diz), mas não vou incluir isso em uma entidade qualquer, incluo na
> entidade de exibição.
Suas duas (mais de duas na verdade) classes modelam uma nota fiscal.
Se você mudar a nota fiscal as duas vão mudar.
> Na verdade, as entidades sequer possuem propriedades com getters e setters,
> somente possuem campos internos. Minhas classes de exibição possuem
> propriedades, já que precisam expor seu estado.
Eu não vejo vantagem nisso. Ao invés de ter as propriedades na classe
que modela o objeto você está movendo as propriedades para outra
classe. Os potenciais problemas relacionados à exposição de estado
continuam presentes.
> A questão não tem nada a ver com questão de eficiência algoritmica. É
> absolutamente conceitual. Dados de tela não são dados transacionais. E por
> isso possuem classes com responsabilidades diferentes.
Bom, você estava falando sobre performance e eficiência então não
entendo como isso "não tem nada a ver com questão de eficiência".
> Se uma NF mudar vou ter que mudar somente a entidade. Não tenho que mudar
> nada nas classes de apresentação.
Ok, digamos então que em vez de:
NF---->Item*
Você passou a ter:
NF--->Grupo*--->Item*
Você certamente vai ter que mudar o objeto de domínio para modelar
esta relação E o código utilizado para gerar seu objeto especializado.
> E se eu precisar apresentar de maneira
> diferente, é só mudar na classe de visão. Por exemplo, digamos que o padrão
> para exibição de nome seja "Nome Sobrenome". Faço isso contatenando os
> campos PrimeiroNome e SobreNome, em um campo único do PM. Se amanhã mudar
> para "Sobrenome, Nome", mudo só o ViewModel. No seu exemplo eu teria duas
> opções: faço o trabalho na visão diretamente, o que enseja realmente
> duplicação de código, já que visões diferentes poderão usar padrões
> diferentes se não duplicarem código, ou seja, deixo à cargo da camada final,
> ou altero meu objeto de domínio para atender uma necessidade da view. São
> duas opções ruins.
Você não precisa duplicar código, basta ter o código que faz
formatação em uma classe reutilizável da Camada de Apresentação
(Camada de Apresentação != View).
Mas note que eu não disse que você não pode ter um PM, pelo contrário.
Em aplicações WPF, por exemplo, eu sinceramente não vejo maneira
melhor de organizar um aplicação.
Jeferson Spencer Chaves
Desculpa pelo tempo em read-only mas gostaria de ter uma dúvida:
- O Giovanni disse que usar propriedades automáticas é anti-pattern. Você fala isso porque um objeto de negócio deve fazer validações antes de receber um valor??? Como isso se comporta se usar um ORM. Eu posso utilizar propriedades mas não as automáticas pra ter algo mais próximo de DDD?
Desculpe-me se estou falando bobagem mas isto é uma dúvida muito forte que me ocorreu.
- Outra pergunta é sobre objetos para visualização. Acho que foi Phillip - me corrijam se estiver errado - que falou sobre presentation model. Bom, o que foi apresentado é que devemos ter um classe para "traduzir" objetos do domínio para objetos de visualização, é isto?
Novamente agradeço,
Jéferson Spencer Chaves
--
------------------------------------------------------------
Jéferson Spencer Chaves
Phillip Calçado
2009/8/4 Jeferson Spencer Chaves <jeferso...@gmail.com>:
> - Outra pergunta é sobre objetos para visualização. Acho que foi Phillip -
> me corrijam se estiver errado - que falou sobre presentation model. Bom, o
> que foi apresentado é que devemos ter um classe para "traduzir" objetos do
> domínio para objetos de visualização, é isto?
O link que passei antes possui muito mais detalhes do que você vai
conseguir encontrar nesta discussão, creio que é melhor você dar uma
lida lá antes e depois comentarmos em cima dele:
http://martinfowler.com/eaaDev/PresentationModel.html
Giovanni Bassi
Alguns ORMs suportam propriedades protected e/ou campos. Eles setam os valores através de técnicas diversas, como Reflection, ou através da utilização de uma classe derivada criada on demmand.
Jeferson Spencer Chaves
Giovanni entendo que você está falando de um ORM tipo nHibernate... Contudo você não acha que isso é um "gambiarra" pro resto funcionar e termos os benefícios de algo tal qual DDD? Isso é parecido o que estavam falando sobre DTOs (eles são um adaptação porque era/é muito complicado ficar criando objetos no servidor e após várias tentativas foi o jeito).
Phillip já tinha lido sobre PM (do Martin Fowler) então só dei uma revisada - muito obrigado. O que entendo que o PM tenta resolver é uma abstração da GUI - me corrija se estiver errado. Contudo não entendi onde os objetos de negócio entram nesta jogada.
Um abraço,
Jéferson Spencer Chaves
Giovanni Bassi
Não acho que é uma gambiarra porque atende requisitos técnicos claros, sem fazer nada de mais. Por exemplo: com uma classe de NF, posso não querer expor minha coleção de itens diretamente, e disponibilizo um factory method que cria itens, e talvez já adicione eles na coleção, e se alguém precisar de acesso aos itens, disponibilizo um IEnumerable, que não permite alteração dos dados.
Reflection tem um custo de performance sim, mas esse custo já fica claro quando você adota um ORM.