Comecei a ler de manhã este artigo do “Srini Penchikala” (Agora eu saiba pronunciar esse nome)
Ainda não terminei, mas ele já tirou várias dúvidas que eu tinha de algumas discussões aqui do GUJ.
Vou citar o que ele escreveu sobre DAO e Repository
E aí Shoes, Sergio, Alezzandro… procede isso?
Mas veja com esse artigo vc irá apenas ter uma visão prática.
Acho que precisa muito mais que isso para realmente aprender DDD, ou seja livro do Eric Evans.
Eu ainda estou em divida com essa leitura.
Não tem nada de novo no que ele falou. O DAO é um DataMapper, é assim que deve ser usado. E a explicação ficou legal mesmo.
Mais pano pra manga…
O que isso tem de novo sobre tudo que rolou em várias threads aqui no GUJ?
http://www.guj.com.br/posts/list/74015.java
http://www.guj.com.br/posts/list/89326.java
http://www.guj.com.br/posts/list/67988.java
http://guj.com.br/posts/list/60/60916.java
Eu tinha linkado o artigo no tópico abaixo:
http://www.guj.com.br/posts/preList/91059/504993.java#504993
Acho que o artigo é importante para sanar as dúvidas surgidas após a tentativa de aplicar os conceitos de DDD após ler o livro do Eric Evans.
De novo…acho que nada.
Na verdade este tutorial não é para ter nada novo. Apenas uma aplicação prática de DDD. Com uma explicação bem sucinta.
De novo nada, mas pode esclarecer muito pra quem nao entendeu DDD ainda.
Pqp quanta prepotencia…
[quote=keller][quote=Emerson Macedo]
O que isso tem de novo sobre tudo que rolou em várias threads aqui no GUJ?
[/quote]
De novo nada, mas pode esclarecer muito pra quem nao entendeu DDD ainda.
Pqp quanta prepotencia…
[/quote]
Nada disso amigo. A pergunta foi por causa do título da Thead e sobre o trecho colado, que foi discutido 896580655454 vezes aqui no GUJ. Portanto, basta ler as threads anteriores que as dúvidas sobre DAOs e Repository estão bem esclarecidas.
E lembrando: foi apenas uma pergunta. Não ofendi ninguém, diferente de você, que me chamou de prepotente.
[quote=Emerson Macedo]O que isso tem de novo sobre tudo que rolou em várias threads aqui no GUJ?
http://www.guj.com.br/posts/list/74015.java
http://www.guj.com.br/posts/list/89326.java
http://www.guj.com.br/posts/list/67988.java
http://guj.com.br/posts/list/60/60916.java[/quote]
Para quem leu e entendeu esses posts nada de mais, apenas a confirmação da diferença entre DAO e Repository.
Talvez a novidade seja a confirmação de que DTO é aceitável em DDD ( aliás porque é necessário para criar o DAO corretamente).
Para quem não leu, ou ainda não entendeu, é uma forma de sublinhar ainda mais que DDD, na prática, tal como qq outra forma de desenvlvimento, depende de padrões. Não apenas dos nomes, mas da forma correta de os usar. Isso implica entendimento de cada um e saber onde os usar. O artigo traça um plano bom para saber usar os padrões nos lugares certos.
Para quem leu com mais atenção vai descobrir que DDD na prática, não é muito diferente da prática sem DDD. Isto porque
se a pessoa conhece OO ela já utiliza, na prática, tudo o que o DDD utiliza. Então, na prática, DDD não é nada especial. É apenas na teoria, na filosofia que ha uma diferença. São as normas que são diferentes, não o resultado.
Então o artigo refresca a ideia de que DDD é mais um DD da vida que trás filosofia diferente, mas que na prática, dá no mesmo. ( TDD, MDD, FDD, SOD(SOA), etc… ). Afinal tudo é OO. Aprenda OO e o resto é perfumaria. Não aprenda OO e tudo isso lhe parecerá extraordinário. O artigo traz as coisas à terra. Muito bom.
Pra mim nunca foi problema usar DTO quando aplicável com DDD ou sem DDD. Agora, ser necessário ter DTOs para criar DAO corretamente pra mim não faz o menor sentido. Tem como você explicar o que você quis dizer?
Porem a apresentação fala um pouco mais do que apenas de “DAO e Repository”.
E se existem tantos topicos é porque com certeza não é um conceito fácil de se absorver. 
Ainda podem surgir mais topicos por ai…
E não foi? Cara desculpe mas essa foi a impressão que ficou pra mim.
Como isso aqui é um forum cada um interpreta da maneira que acha melhor/pior.
Foi mal então… 
A intenção foi avisar ao colega que o conteúdo do corpo da mensagem dele (que foi DAO e Repository) já foi esclarecido em diversos tópicos. Se pareceu algo ofensivo, me desculpe, não foi essa a intenção.
Pra mim nunca foi problema usar DTO quando aplicável com DDD ou sem DDD. Agora, ser necessário ter DTOs para criar DAO corretamente pra mim não faz o menor sentido. Tem como você explicar o que você quis dizer?[/quote]
É 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
Você que disse que DTO era aceitável em DDD, não fui eu. Eu nunca vi problema, pois DDD não trata de DTOs, portanto usar DTOs e DDD num mesmo projeto é perfeitamente possível, isso se você realmente precisar de DTOs, que na maioria dos casos são usados de maneira equivocada.
E você continua estuprando o conceito de DTOs apesar do pessoal do forum (eu inclusive) já ter te passado diversas referências confiáveis sobre o padrão em outras threads.
[quote=Emerson Macedo]Você que disse que DTO era aceitável em DDD, não fui eu.
[/quote]
Não fui eu que disse. Eu disse que o artigo menciona isso. E eu disse que isso (a menção) pode ser uma surpresa. Sobretudo para quem acha que DTO não têm utilidade num ambiente DDD com seus entity e Value Objects e Specifications e objetos com dados e comportamento juntos…
Nem eu… nem eu…
[quote]
E você continua estuprando o conceito de DTOs apesar do pessoal do forum (eu inclusive) já ter te passado diversas referências confiáveis sobre o padrão em outras threads.[/quote]
Tão confiáveis como as que confundem DAO com Repositorio e não sabem a diferença entre TO e DTO ?
Quiça confiáveis como as que dizem que DTO são uma praga mal usada pelos desenvolvedores ao nivel de um anti-pattern ? Tlv confiáveis como as que apontam DAO genéricos construidos com Hibernate ? Talvez confiáveis com as que defendem que podem haver várias cópias de um singleton. Tlv confáveis como as que defendem que padrões de projeto são irrelevantes e atrapalham mais que ajudam. Vamos lá… afinal o que interessa a confiabilidade das fontes ? Estamos fazendo algum trabalho jornalistico ? Não me parece…
Vc discorda que o DAO tenha que ser reaproveitável entre projetos ? (se não for ,para que serve então ?)
Discorda que o DAO receba QueryObjets como parametro de pesquisa ? (até uma string com sql lá dentro é um QueryObject - um muito ruim- mas um … mesmo assim)
Discorda que tornar o DAO dependente / acoplado a objetos especificos do dominio o torne inreaproveitável ? ( senão, então o que o torna inreaproveitável ?)
Afinal, quantas vezes vc reaproveitou um DAO de um projeto em outro ?
O que respondem as suas fontes a estas perguntas ? E onde essas respostas mostram o crime de estupro de que me acusa ?
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.
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:
E o Core J2EE Patterns também diz que Domain Store usa DAO:
E -muito interessante- fala que esse DAO pode popular o objeto de negócio:
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).
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.
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.
[quote=Paulo Silveira][quote=sergiotaborda]
É 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
[/quote]
mas isso nao eh horrendo? tem a entidade Entidade e vamos criar EntidadeDTO so porque o DAO nao deveria falar com Entidade?
[/quote]
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.
[quote]
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.[/quote]
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!!
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) ? :lol: :lol: :lol:
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. :shock: :?
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.