Agora não há desculpa para não entender DDD

sergiotaborda wrote:
É estranho. Esparava que fosse ao contrario (estranhar o uso de DTO e aceitar que DAO usa DTO)

DTO é estranho em DDD porque DDD é orientado ao dominio e DTO não é dominio, é infra. Usa-se porque é preciso, não porque é bonito ou desejável. Mas o principal é que DTO é um objeto só de dados, sem regras, e isso parece ir contra o conceito de Entity ( eu disse parece)

Uma implementação correta de DAO é reutilizável e independente do programa onde é usada. Para isso ser alcançado
ela não pode cuspir objetos de dominio nem aceitar objetos de dominio. Logo, ha que usar intermediários. o DAO cospe DTO e aceita QueryObject para pesquisa e DTO para edição. O DTO pode ser algo simples como um Map

mas isso nao eh horrendo? tem a entidade Entidade e vamos criar EntidadeDTO so porque o DAO nao deveria falar com Entidade? Ai copiamos e colocamos seus atributs, etc, so por um capricho desse tamanho?

Voce mesmo falou Sergio um tempo atras, e eu concordei, que DTO eh pra voce acertar o tamanho da granularidade de requests/responses entre TIERS, nunca entre LAYERS.

De qualquer maneira, mesmo que voce concorde com isso, acho que ai o nome nao deveria chamar DTO, ja que esse padrao eh pra tier. E eu nao concordo com o uso de qualquer XO so pra separar o DAO de tocar entidades. Pra mim é o cumulo da arquitetura cebola.

This message was edited 1 time. Last update was at 19/06/2008 05:25:46

Fowler não sabe a diferença entre TO e DTO. (lembrando que Value Object era como era chamado o Transfer Object, que mudou de nome exatamente pelo trabalho de Evans & Fowler).

O core J2EE Patterns é caro sobre a utilidade do TO:

A Transfer Object is designed to optimize data transfer across tiers. Instead of sending or receiving individual data elements, a Transfer Object contains all the data elements in a single structure required by the request or response.

E o Core J2EE Patterns também diz que Domain Store usa DAO:

Core J2EE Patterns, 2a Edicao wrote:
Participants and Responsibilities

Figure 8.16 shows the class diagram for the Domain Store core classes. The following is a listing of the classes.
[...]
* StoreManager (Data Gateway [PEAA]) ? Interacts with the data resource to perform CRUD operations. The StoreManager is a DAO and encapsulates all the data resource mechanisms.

E -muito interessante- fala que esse DAO pode popular o objeto de negócio:

* The StoreManager might populate the BusinessObject rather than the PersistenceManager

E não fala sobre DAOs aproveitáveis entre projetos (o que, aiás, cairia em integração via BD, que não é lá algo muito legal).

Mas eu não sei porque insisto em citar referências. É mais que claro que não ler o livro nunca impediu ninguém de falar sobre o que é CERTO ou ERRADO (como se existissem).

Tão confiáveis como as que confundem DAO com Repositorio e não sabem a diferença entre TO e DTO ?

Como foi dito por outros colegas aqui do forum, não existe verdade absoluta. Porém, quando nossa ideia está indo totalmente contra o que foi passado nas melhores referências, isso pode ser um sinal de que estamos distorcendo alguma coisa. Acho que você deveria pensar por esse lado, pois seus argumentos quanto ao uso de DTOs não estão nem um pouco embasados nas melhores literaturas. Talvez você possa chamar isso que você está propondo de outra coisa. Creio eu que seria mais interessante do que insistir que isso é um DTO.

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

Olá,

Eu prefiro que os DAO's possam acessar as entidades numa boa. Logo meus repositórios são apenas uma interface e o DAO usualmente acaba por implementar o repositório. Essa é minha forma favorita.

No entanto, num projeto atual estamos aplicando algumas idéias do DDD, inclusive o Repositorio. Foi inevitável: outras pessoas acharam um absurdo o DAO tocar as entidades. No nosso caso a situação é um pouco diferente: 'existe uma equipe que foca apenas os DAO's'. Então a discussão acabou indo para o meio termo. O repositorio passou a ser uma implementação e esta por sua vez delegava para o DAO. O DAO não conhece as entidades, mas sim alguns objetos comuns representando os dados que ele buscava. O repositório acessa este objeto comum e mapeia pra entidade. Cada um cedeu um pouquinho e beleza.

A questão é que concordo que não existe certo ou errado. Como já li algumas vezes aqui no GUJ, o termo apropriado e não apropriado são bem menos agressivos.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 1897 Offline

Paulo Silveira wrote:

sergiotaborda wrote:
É estranho. Esparava que fosse ao contrario (estranhar o uso de DTO e aceitar que DAO usa DTO)

DTO é estranho em DDD porque DDD é orientado ao dominio e DTO não é dominio, é infra. Usa-se porque é preciso, não porque é bonito ou desejável. Mas o principal é que DTO é um objeto só de dados, sem regras, e isso parece ir contra o conceito de Entity ( eu disse parece)

Uma implementação correta de DAO é reutilizável e independente do programa onde é usada. Para isso ser alcançado
ela não pode cuspir objetos de dominio nem aceitar objetos de dominio. Logo, ha que usar intermediários. o DAO cospe DTO e aceita QueryObject para pesquisa e DTO para edição. O DTO pode ser algo simples como um Map

mas isso nao eh horrendo? tem a entidade Entidade e vamos criar EntidadeDTO so porque o DAO nao deveria falar com Entidade?

Antes de mais, deixe-me esclarecer que estou-me atendo ao conceito de DAO e Repositorio passado no proprio artigo referido no inicio do thread.

Nesse contexto, não é horrendo porque simplesmente não existe. Vc está assumindo que tem que criar um EntidadeDTO e jogar ele no DAO. Ora, isso vai exactamente contra o conceito de que o DAO é independente do dominio.
Ora, se vc espera que o DAO receba um objeto que depende do dominio (EntidadeDTO depende do dominio porque Entidade depende do dominio) isso que vc tem ai não é um DAO.

A lógica é simples: Axioma: DAO é independente do dominio. Corolário: se é dependente não é um DAO.

Então o que é ?
O artigo responde a isso também. Se manipular entidades e servir para localização ele é um Repositorio. Se for apenas um transformador entre DTO e outra coisa (specification, entidade, VO ,etc...) então é um DomainDelegate.

Voce mesmo falou Sergio um tempo atras, e eu concordei, que DTO eh pra voce acertar o tamanho da granularidade de requests/responses entre TIERS, nunca entre LAYERS.

De qualquer maneira, mesmo que voce concorde com isso, acho que ai o nome nao deveria chamar DTO, ja que esse padrao eh pra tier. E eu nao concordo com o uso de qualquer XO so pra separar o DAO de tocar entidades. Pra mim é o cumulo da arquitetura cebola.

O problema com esta conversa é sempre o mesmo: nomenclatura e contexto. Ha uma dificuldade em seguir nomenclaturas dentro de um contexto. Neste topico o contexto é o artigo do cara.

O DTO do artigo não é só para Tiers !! 'das!!

o artigo wrote:
DTO's are also an important part of the design in an SOA environment where the Domain object model structurally is not compatible with the messages that are received and sent from a business service. The messages are typically defined and maintained in as XML Schema Definition documents (XSD's) and it's a common practice to write (or code generate) DTO objects from the XSD's and use them for data (message) transfer purposes between domain and SOA service layers.

Por outro lado, é impossivel algo passar entre tiers se não passar entre layers primeiro ( lembre-se do stack TCP por exemplo)

---

não me lembro de ter concordado consigo nisso, mas eu sempre defendi que eles são a mesma coisa

Mesmo que vc faça a destinção entre eles, isso se resume a se implementa Serializable ou não.
Ha uma variante que é um pouco mais diferente ( not really) que implica em comprimir a serialização. Isso sim é um DTO real. O nome DTO adveio dese padrão de compressão. Mas como num objeto so com atributos não ha o que comprimir o JEE COre Patterns passou a ideia de que o DTO era apenas um conjunto de atributos serializáveis e pronto. Não é apenas isso. O DTO original continha mecanismo de compressão (por exemplo, listas que nsó serializam os objetos realmente diferentes).
Hoje em dia DTO e TO são a mesma coisa. E não ha essa diferença tão destinta entre tier e layer. Aliás, se ler o JEE Core Patterns vai entender que eles usam os dois termos meio que indestintamente.
A destinção não é tão rigida como faz pensar.

Quer chamar outro nome ? blz. Qual nome ? Como se chamaria um objeto utilizado para o único propósito de transportar informação entre "regiões" diferentes do sistema ? eu acho "Transfer Objet" bem obvio, mas proponha um nome para a gente se entender da proxima vez... ma lembre-se que ninguem irá utilizá-lo e depois vai criar confusão...
Que tal *TO ( tal como em WS*) ?

Emerson Macedo wrote:
Talvez você possa chamar isso que você está propondo de outra coisa. Creio eu que seria mais interessante do que insistir que isso é um DTO.

Eu não estou propondo nada. Estou usando o que é comum, o que está escrito no artigo. ( é disso que trata o topico, não?)

Eu leio a mesma coisa que todo o mundo. Acho incrivel acharem que sou louco (ou estrupador) apenas porque meus conceitos coincidem com os dos caras que escreveram o que li. Se o meu conceito de que um DTO é algo que viaja em "regiões" da aplicação independentemente de serem Tiers ou Layers está errado , então o do Srini Penchikala ambém está, porque é o mesmo e eu sou culpado de ser coerente e entender o que leio.

Afinal qual é o vosso conceito de DTO. Alguma referencia confiável sobre a diferença ?
(Para quem não entendeu ainda: porque a diferença não existe é que eu coloquei em causa a confiabilidade de uma referencia que fala sobre a diferença)

Alguem perguntou o que havia de novo no artigo. Parece que o que ha de novo no artigo é entender o real conceito de DTO.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 1897 Offline

Thiago Senna wrote:Olá,

Eu prefiro que os DAO's possam acessar as entidades numa boa. Logo meus repositórios são apenas uma interface e o DAO usualmente acaba por implementar o repositório. Essa é minha forma favorita.

Porque não jogar a casa pela janela e complicar as coisas e chamar tudo um nome só ? que tal :"Objecto de não-quero-por-a-mao-no-jdbc-porque-é-chato-e-brega" ?
Repositorio interface do DAO... essa é boa. Mas isso é outra conversa....

No entanto, num projeto atual estamos aplicando algumas idéias do DDD, inclusive o Repositorio. Foi inevitável: outras pessoas acharam um absurdo o DAO tocar as entidades. No nosso caso a situação é um pouco diferente: 'existe uma equipe que foca apenas os DAO's'. Então a discussão acabou indo para o meio termo. O repositorio passou a ser uma implementação e esta por sua vez delegava para o DAO. O DAO não conhece as entidades, mas sim alguns objetos comuns representando os dados que ele buscava. O repositório acessa este objeto comum e mapeia pra entidade. Cada um cedeu um pouquinho e beleza.

Vc faz parecer que é uma questão de politica. Uma questão de convencer as pessoas.
Nas realidade é um fato. Nas sua palavras é assim que é mais apropriado. E isso é um dado conhecido à partida
e independente de quem está no projeto e de qual é o projeto o uda opinião de quem quer que seja. Por isso é um padrão!!!

A questão é que concordo que não existe certo ou errado. Como já li algumas vezes aqui no GUJ, o termo apropriado e não apropriado são bem menos agressivos.

Eufemismos é para quem é fraco de espirito. (no pun intended)

sergiotaborda wrote:
...
E não ha essa diferença tão destinta entre tier e layer. Aliás, se ler o JEE Core Patterns vai entender que eles usam os dois termos meio que indestintamente.
A destinção não é tão rigida como faz pensar.
...

Maltratar o português como você fez, ao escrever uma palavra que não existe: destinta, destinção , indestintamente e as pessoas, também pode ser sinal de fraqueza de espírito.

sergiotaborda wrote:
...
E não ha essa diferença tão destinta entre tier e layer. Aliás, se ler o JEE Core Patterns vai entender que eles usam os dois termos meio que indestintamente.
A destinção não é tão rigida como faz pensar.
...

Sergio, voce que sempre falou pra gente nao acreditar em tudo que a gente le. Eh um GRAVE erro nao distinguir entre layers e tiers, em especial por causa da granularidade e excesso de roundtrips de comunicacao entre tiers.

Imagine agora ficarmos criando DTO pra jogar pro JSP???? Temos Entity pro dominio, EntityJSP pra enviar pra EL, EntityTO/DTO/XO pro DAO, EntityBLABLA pra outro layer, etc... mega BOLOVO... Entendo que voce estava contextualizando no artigo, mas queria saber se voce no dia a dia faz assim: cria uma OUTRA classe pra usar dentro do DAO, e se tambem faz isso pra jogar pro JSP.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 1897 Offline

luiz_ross wrote:
Maltratar o português como você fez, ao escrever uma palavra que não existe: destinta, destinção , indestintamente e as pessoas, também pode ser sinal de fraqueza de espírito.

É verdade. Isso chama-se texlexia, não é de propósito... mea culpa.

Respondendo ao criador do tópico:

vlw!!! excelente artigo =D

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 1897 Offline

Paulo Silveira wrote:

sergiotaborda wrote:
...
E não ha essa diferença tão destinta entre tier e layer. Aliás, se ler o JEE Core Patterns vai entender que eles usam os dois termos meio que indestintamente.
A destinção não é tão rigida como faz pensar.
...

Sergio, voce que sempre falou pra gente nao acreditar em tudo que a gente le. Eh um GRAVE erro nao distinguir entre layers e tiers, em especial por causa da granularidade e excesso de roundtrips de comunicacao entre tiers.

Não confuda as coisas. O que não é destinguivel é DTO e TO. Layer e Tier são destinguiveis.
Só que a palavra "tier" em ingles tem dois significados : máquina e andar.
layer é tb dois singificados : camada e andar.
Falemos em portugues.
camada = conjunto de classes com um proposito. O DAO é uma camada.
nodo = máquina (máquina virutal,claro)
andar = conjunto de camadas que compoe funcionaldiade da aplicação ( apresentação, integração, negocio etc)

Um objeto precisa ser serializável para viajar entre nodos.
Em uma arquitetura n-nodos vc tem, em cada nodo, vários andares e camadas.

então , por exemplo, se vc tem um DAO no servidor que comunica com o banco
e um DAO no cliente comunica com o DAO no servidor através de alguma tencologia , digamos REST, então vc tem
informações viajando de um DAO para o outro. Essas informações viajam entre 2 nodos, mas não saem , nem do mesmo andar ,nem da mesma camada.

Agora pense num processo de log (log4j - camada) que envia um objeto através da rede para ser guardado no banco.
Esta mensagem atravessa nodos, camadas e andares diferentes.

O que vcs estão dizendo é que um objeto que atravessa apenas nodos é de um tipo e tem um padrão especifico. E o objecto que atravessa apenas camadas ou andares ( no mesmo nodo) é um outro padrão com outro nome.
O que eu estou dizendo é que é o mesmo objeto. O DAO cliente ou o Appender do cliente não sabem que são "o cliente" eles são partes do sistema. Se o sistema for standalone esses caras seriam o fim da linha e o objeto não viajaria entre nodos. Mas isso pode mudar rápidamente ( polimorfismo) e ai o objeto tem que viajar pelos nodos. Não muda o objeto nem muda a aplicação.
Para poupar tempo o objeto já é definido como serializável se anda entre nodos, mas como Serializable é um marcador, tanto faz. Vc pode marcar sempre um objeto com essa interface se ele pode, um dia, quando necessário, ser serializável.
O padrão para transferir informações ( dados ) é o Transfer Object. Data Transfer Object é o mesmo nome mais completo. não sei qual é o problema em entender/aceitar isso. O uso é o mesmo. Não tem essa de diferenciar entre camadas, andares e nodos porque essa estrutrua é dinamica. Se o objeto viaja, ele tem que viajar de onde for preciso para onde for preciso, sejam esses lugares onde forem.

Não sei como explicar melhor.

Imagine agora ficarmos criando DTO pra jogar pro JSP???? Temos Entity pro dominio, EntityJSP pra enviar pra EL, EntityTO/DTO/XO pro DAO, EntityBLABLA pra outro layer, etc... mega BOLOVO... Entendo que voce estava contextualizando no artigo, mas queria saber se voce no dia a dia faz assim: cria uma OUTRA classe pra usar dentro do DAO, e se tambem faz isso pra jogar pro JSP.

Perai, eu não disse que tem que usar DTO em tudo quanto é canto.
O que eu disse é muito simples e é aquilo que o Thiago Senna exemplificou.
É a implementação do DAO que não usa nada que seja o dominio e como tal tem que usar um objeto de transferencia de dados independente do dominio.
Esse objeto pode ser um simples Map ou algo semelhante. É um objeto qualquer que o DAO define como parte da sua interface ( surface area) e pronto. É o DAO que define qual objeto vai ser e não o dominio. É só isso.

Pronto, chame esse objeto como quiser. Eu chamo de TO o cara do artigo chamou de DTO - que é a mesma coisa! - vc pode inventer outro nome. Que tal Cross-Region Data Object (CREDO) ?

Primeiro...

sergiotaborda wrote:...Tão confiáveis como as que confundem DAO com Repositorio e não sabem a diferença entre TO e DTO ?

Depois..

sergiotaborda wrote:Eu chamo de TO o cara do artigo chamou de DTO - que é a mesma coisa!

Sergio,
Até onde eu sabia era isso que o Shoes passou.

...finalmente tem alguma diferença entre DTO e TO ?

sergiotaborda wrote:
Pronto, chame esse objeto como quiser. Eu chamo de TO o cara do artigo chamou de DTO - que é a mesma coisa! - vc pode inventer outro nome. Que tal Cross-Region Data Object (CREDO) ?

So se fosse numa fabrica de crucifixos. Ai temos a entidade Cruz e o objeto CruzCREDO, assim as pessoas ja ficam sabendo o que vem por ai

This message was edited 1 time. Last update was at 20/06/2008 11:14:07

leofernandesmo wrote:Primeiro...

sergiotaborda wrote:...Tão confiáveis como as que confundem DAO com Repositorio e não sabem a diferença entre TO e DTO ?

Depois..

sergiotaborda wrote:Eu chamo de TO o cara do artigo chamou de DTO - que é a mesma coisa!

Sergio,
Até onde eu sabia era isso que o Shoes passou.

...finalmente tem alguma diferença entre DTO e TO ?

A referencia ao Fowler é totalmente fora de contexto. VO pela definição do Fowler são coisas para usar no dominio. São "not so small small data types". Eles são usados para adicionar significado semantico aos objetos dentro do dominio.
TO é um objeto usado para transportar informação entre regiões do sistema. Ele é especificamente contruido para isso.
Um Value Object ou um Entity que viaje entre regiões não será um TO. Embora ele tenha exactamente as mesmas caracteristicas - o proposito não é o mesmo ( lembrar que um padrão é criado para resolver um problema e existe forças a favor e contra ele. Ele soluciona o problema. Quando o problema não existe, o padrão não se aplica)
Portanto, VO e TO não têm nada a haver um com o outro, exeto na questão historica ( que o link não menciona e portanto é irrelvante detalhar aqui)

Saber a diferença entre A e B implica em primeiro lugar que exista uma diferença. Claro que sempre existirá uma diferença, nem que seja no nome, mas me referia à diferença no conceito. Essa é a diferença que interessa. É como subir e ir para cima. Não é a mesma coisa, mas pode ser facilmente confundido. Quem se colocar na posição de que DTO e TO são conceitos diferentes tem que explicar a diferença do conceito. Mas a diferença de conceito não existe, são apenas dois nomes para a mesma coisa. Ha uma diferneça de nomenclatura, uma diferença historica, etc... mas não no conceito.

A primeira frase é uma critica à confiabilidade de uma referencia que optar por dizer que DTO e TO são conceitos diferentes, com usos diferentes , etc.. A segunda é uma chamada de atenção para que o conceito é o mesmo.
Uma é o reforço da outra. Já que, se o conceito é o mesmo, dizer que é diferente não é confiável.

sergiotaborda wrote:
E não ha essa diferença tão destinta entre tier e layer. Aliás, se ler o JEE Core Patterns vai entender que eles usam os dois termos meio que indestintamente.
A destinção não é tão rigida como faz pensar.

Acho que você deve ter lido o livro em português, onde a tradução como de costume péssima, chama tudo de camada, não fazendo distinção entre Layer e Tier.