Arquivo Discussoes de Programacao e Tecnologia 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…
O que isso tem de novo sobre tudo que rolou em várias threads aqui no GUJ?
De novo nada, mas pode esclarecer muito pra quem nao entendeu DDD ainda.
Pqp quanta prepotencia…
E lembrando: foi apenas uma pergunta. Não ofendi ninguém, diferente de você, que me chamou de prepotente.
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
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?
É 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.
Você que disse que DTO era aceitável em DDD, não fui eu.
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…
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.
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.
É 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!!
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.
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…
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)
Maltratar o português como você fez, ao escrever uma palavra que não existe: [size=18]destinta[/size], [size=18]destinção [/size], [size=18]indestintamente[/size] e as pessoas, também pode ser sinal de fraqueza de espírito.
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.
Maltratar o português como você fez, ao escrever uma palavra que não existe: [size=18]destinta[/size], [size=18]destinção [/size], [size=18]indestintamente[/size] 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
…
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.
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) ? :lol: :lol: :lol: :lol:
Primeiro…
Depois…
Sergio,
Até onde eu sabia era isso que o Shoes passou.
…finalmente tem alguma diferença entre DTO e TO ?
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 
Primeiro…Depois…
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.
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.
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.
Você acha demasiadas coisas de mim … :shock:
Eu só leio livros tecnicos dessa importância em ingles.
Você achas demasiadas coisas de mim … :shock:
Eu só leio livros tecnicos dessa importância em ingles.
[size=24]Transfer Object[/size][size=18]Problem[/size]
You want to transfer multiple data elements over a tier.[size=18]Forces[/size]
[list]You want clients to access components in other tiers to retrieve and update data.[/list]
[list]You want to reduce remote requests across the network.[/list]
[list]You want to avoid network performance degradation coused by chattier applications that have high network traffic.[/list]
[size=18]Solution[/size]
Use a Transfer Object to carry multiple data elements across a tier.
Eu não tenho o livro agora comigo, então vou-lhe responder depois.
Mas a sua resposta esclarece a dúvida do Paulo Silveira:
Como se pode ver, o TO também é para tier.
Na falta do livro e só para não deixar cair a peteca no chão
Esta referencia explica detalhadamente o que eu falei de usar DAO e TO.
Segundo o Paulo Silveira isto seria um uso entre layers. Então, esta passagem mostra o mesmo padrão sendo usado para outra finalidade de que apenas transferir dados entre tiers.
No exemplo 9.5 pode ser vista implementação de um TO implementando Serializable ( o que permite entender que vai acontecer uma trasnferencia entre nodos em algum momento, ou seja, ele vai viajar entre tiers.)
Básicamente esta referencia resume o que eu já falei aqui em outras palavras.
Então, pegando o fio da meada:
O ponto é que o JEE Core Patterns ( que é uma referencia no assunto porque práticamente inventou o TO) usa o TO indescreminadamente para transportar informações entre layers e tiers ( ou em português, camadas, andares e nodos)
O Emerson deu o exemplo entre tiers (nodos)
Na página 413 da segunda edição podemos ler :
(Itálico no original)
Aquele “client” ali não é outra máquina é o utilizador do objeto Composite Entity, ou seja , é outro objeto, em outro andar (tier). Ele poderá estar, eventualmente em outra máquina (tier) mas isso é um detalhe.
O exemplo que passei antes que pode ser lido em mais detalhes na página 467 do livro mostra o TO sendo usado com o DAO e isso , por definição, é uma passagem entre layers ( camadas ).
Quem quiser ler o livro todo esteja à vontade. O ponto é: o Core J2EE Patterns sim usa o TO indestintivamente entre layers e tiers ( em detalhes : camadas, andares e nodos) tal como eu havia dito.
Eu não me importe de explicitar o obvio, mas é cansativo. Será que é pedir muito que primeiro leiam, ou releiam, as coisas antes de argumentar ? Poupa muito tempo.
Será que da próxima vez ainda haverá alguém colocando em duvida o uso do TO ?
Será que da próxima vez ainda haverá alguém colocando em duvida como se implementa um DAO ?
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.
:idea: Emerson, como você tem dificuldades sérias de entender as coisas, ainda bem que as pessoas aqui tem paciência com você …
:lol: :lol: :lol:
Independente das discussões entre DTO e sua classificação entre Tiers e Layers, volto a discussão para a questão da independência do DAO frente aos Repositórios.
De fato, é possível e simples possuir uma interface de um DAO independente do domínio da aplicação. A dependência pode estar no DataMapper mas totalmente isolada na API do DAO.
Para aqueles que usam Hibernate puro como um “DAO” e um CRUD simples de forma simplificada:
public class HibernateDao implements Dao{
//injetado via DI
Session session;
public void save(Object obj){
session.save(obj);
}
public void update(Object obj){
session.update(obj);
}
public void delete(Object obj){
session.delete(obj);
}
public List find(String query){
return session.createQuery(query).list();
}
}
Essa classe (draft, por favor) não tem referência direta alguma a qualquer entidade do domínio. O método find tem um débito técnico que é receber como parâmetro String, mas que poderia ser solucionado recebendo um QueryObject com tradução para a HQL, por exemplo.
Não é muito difícil, fazer uma implementação específica para OJB, Kodo API ou JPA por exemplo, com esta mesma interface.
Um Repositório sem conhecer apis de infra de um DAO:
public class RepositorioUsuario{
//injetado
Dao dao;
public void adicionar(Usuario usuario){
dao.save(usuario);
}
//assinaturas relevantes ao dominio
//(melhor sua portabilidade se usar QueryObjects mais abstratas, claro)
public List<Usuario> buscarUsuariosAtivos(){
dao.find("from Usuario usr where usr.ativo = true");
}
// um repositorio isolado da implementacao de um DAO pode
//conter regras específicas para seus serviços
// como no método abaixo
public void remover(Usuario usuario){
dao.delete(usuario);
//regra relacionada a infra e rastreabilidade,
//porém para um requisito pertinente somente em
//casos de exclusão de Usuario
//Lembrando que 'UsuarioHistorico' nem mesmo é
//uma entidade em relação ao domínio
UsuarioHistorico usuarioHistorico = UsuarioHistoricoFactory.create(usuario);
dao.save(usuarioHistorico);
}
O repositório faz o que se propõe a fazer e satisfaz sua motivação. O DAO continua na dele e isolado do domínio.
Antes que o assassinato de patterns continue, repetindo: Na época do Lançamento do POEAA a Sun chamava o TO de VO -basta checar a primeira edição do livro ou mesmo o wbsite da Sun que até hoje Não atualizou os diagramas. A referência do Fowler cita o que o VOd a Sun é o mesmo que o DTO dele e que VO para ele é uma outra coisa. Após este livro a Sun renomeou o padrão J2EE para TO.
Logo, repetindo mais uma vez: Fowler não sabe a diferença entre TO e DTO. Que burro, dá zero pra ele.
Como todas as outras referências (dos autores dos conceitos) continuam contrariando boa parte do que foi dito neste tópico elas continuam aí.
hmm… alguma referencia sobre essa origem “nobre” dos DTOs? CORBA?
É pena que toda discussao sobre domain -driven design descambe pra banco de dados…
Interessante. Nesse semestre na faculdade eu precisei fazer um projeto usando somente JSP, Servlets e JDBC. Meu DAO ficou da forma como você indicou, mas com uma diferença:public class HibernateDao implements Dao{ //injetado via DI Session session; public void save(Object obj){ session.save(obj); } public void update(Object obj){ session.update(obj); } public void delete(Object obj){ session.delete(obj); } public List find(String query){ return session.createQuery(query).list(); } }
interface DAO<T> {
void add(T t);
void update(T t);
void delete(T t);
void find(String query, Object[] parameters);
}
Como mencionei Tarso, é um draft e não uma implementação que descrevi. Com certeza teria para o “find” uma lista de parâmetros no código de produção além de outras coisas.
Mas essa lista de parâmetros (ou como tbm mencionei, um QueryObject com diferentes traduções e argumentos), não tem nada específico de qualquer API… logo não é dependência.
Como mencionei Tarso, é um draft e não uma implementação que descrevi. Com certeza teria para o “find” uma lista de parâmetros no código de produção além de outras coisas.Mas essa lista de parâmetros (ou como tbm mencionei, um QueryObject com diferentes traduções e argumentos), não tem nada específico de qualquer API… logo não é dependência.
[EDIT]
Ahhhh… O método find do DAO que eu mostrei tá errado… Ele deve retornar um List<T>.
[/EDIT]
Eu já nem entro mais nessas discussões… não adianta… quando será que vocês vão compreender que DDD não é sobre padrões? O nível de cerimônia e de débito técnico pode variar entre as aplicações. Não dá pra pegar a literatura e aplicar "as-is" como uma cartilha.
Vou falar uma coisa aqui que posso até ser crucificado por vocês: uma aplicação com domínio anêmico na implementação pode ser desenvolvida usando DDD. Depende do domínio. 8)
Um Active Record do Ruby é manifestado declarando claramente dependência de infra:
class PedidoVenda < ActiveRecord::Base
...
end
Creio que na opinião de vocês não dá pra desenvolver nada em DDD no Rails. Só no mundinho hermético onde temos Entities, Hibernate, DAOs, Camadas é que podemos ter DDD, certo?
Vamos imaginar que eu consiga manifestar um conceito de domínio na "YoshiLanguage" da seguinte maneira:
Pedido é Entidade
Código é Número-Inteiro
Cliente é Empresa
Valor-Total é Número-Decimal
Itens é Item-Pedido[]
Status é Em-Aberto, Aprovado, Entregue, Cancelado
Fim
Pedidos é Repositório de Pedido
Cancelados é cada Pedido onde Status = Cancelado
Fim
TelaPedido é Tela
Tabela-de-Pedidos é Tabela
Iniciar
Tabela-de-Pedidos popular-com Pedidos.Cancelados
Fim
Fim
Vocês poderiam dizer que nessa listagem não estamos usando DDD por que os padrões não estão claros como na literatura ou porque tenho dependências de conceitos da minha implementação?
Eu já nem entro mais nessas discussões… não adianta… quando será que vocês vão compreender que DDD não é sobre padrões? O nível de cerimônia e de débito técnico pode variar entre as aplicações. Não dá pra pegar a literatura e aplicar "as-is" como uma cartilha.
Acho que você viajou aqui, Rodrigo. Ninguém, até onde eu lembro, está comentando sobre Domain-Driven Design em si e sim sobre os padrões de apoio.
Falar isso sem dar um exemplo ou embasamento é uma afirmação vazia.
Além de você estar colocando palavras no texto de todos aqui (estamos discutindo sobre padrões, não sobre aplicação de DDD em si) essa afirmação é meio sem-sentido. Repository não fala sobre a implementação de persistência, por exemplo, e nada impede de usar AR e Repository, apesar de que você provavelmente vai fundir Entity e Repository no mesmo objeto -se isto é bom ou não é outra história. Ainda assim não existe qualquer obrigação em Rails de se seguir DDD, aliás a maioria dos projetos Rails que vi não seguem, então qual seu ponto?
Novamente: você está confundindo uma discussão sobre padrões com uma discussão sobre Domain-Driven Design. Não é porque eu não preciso dos padrões clássicos para ter DDD que eu não posso discutir sobre implementações dos padrões.
Dicordo Tarso. Se você vai fazer uma query parametrizada com HQL ela tbm vaio ter os parâmetros, assim como uma EJBQL ou até mesmo uma QueryByExample de sua implementação de QueryObjects. Se você fosse fazer uma pesquisa em uma árvore LDAP, você tbm pode utilizar esta lista de parâmetro cromo critérios da pesquisa.
O título do post é “Agora não há desculpa para não entender DDD”. O artigo está bem focado em DDD e nem tanto em Domain Patterns. Por que essas discussões sempre descambam pra mesma discussão que já falamos aqui mais de 10.000 vezes?
Imagine que você está desenvolvendo uma aplicação baseada em transações no Mainframe. Dentro do mundo de transações você precisa definir quais transações são necessárias para seu sistema. Nesse aspecto sua ubiquitous language pode se basear em “dados de entrada” e “dados de saída” e a transação ser um Service. O escopo da sua aplicação não é o Mainframe, mas sim externalizar isso. Você poderia usar DDD num típico modelo anêmico.
Sorry… foi provocativo mesmo… queria ver respostas de outros aqui… não deu certo. 
Novamente: você está confundindo uma discussão sobre padrões com uma discussão sobre Domain-Driven Design. Não é porque eu não preciso dos padrões clássicos para ter DDD que eu não posso discutir sobre implementações dos padrões.
O problema é que as literaturas dão exemplos de implementação e não regras de implementação. Tomar os exemplos como regras é uma rigidez conceitual arriscada. Você mesmo concorda que não há CERTO ou ERRADO, eu particularmente não gosto quando dizem “não deve tocar”, “nunca deve depender”, “não é correto”. Algumas pessoas podem errar um padrão por desconhecer, outras podem tomar decisões fugindo da literatura baseadas em risco e benefício.
O problema é que as literaturas dão exemplos de implementação e não regras de implementação. Tomar os exemplos como regras é uma rigidez conceitual arriscada. Você mesmo concorda que não há CERTO ou ERRADO, eu particularmente não gosto quando dizem “não deve tocar”, “nunca deve depender”, “não é correto”. Algumas pessoas podem errar um padrão por desconhecer, outras podem tomar decisões fugindo da literatura baseadas em risco e benefício.
Talvez não haja o certo, mas com certeza ha o errado. Desse ponto de vista, o certo é não fazer errado.
Em outras palavras: existem best pratices(melhores práticas) e bad pratices (más práticas). O certo é seguir as melhores práticas e abandonar/não seguir as más práticas. Acho que isso é passivelmente aceitável.
Agora atenda ao nome “melhores práticas”. “prática” aqui, não opoe a teoria, mas significa apenas “experiencia empirica”. Ou seja, de tanto trabalhar com a coisa, as pessoas já descobrir formas mais eficientes de trabalhar com elas ( e também as formas menos eficientes). Isto, acho, também é obvio.
O que tlv não seja tão obvio - tlv nasça a ideia de que ha um certa prepotência nas afimações - é que as melhores práticas podem ser deduzidas de principios primeiros, fundamentais, da OO e de outras áres relacionadas a desenvolvimento ( pro exemplo, melhores práticas de construção de UI não vêm de OO, vêm de disciplinas como a ergonomia e em ultima análise da teoria das cores e da arte).
Deste ponto de vista os principios fundamentais ( como o Principio de Separação de Responsabilidade) são a “melhor teoria” de onde pode ser derivada a melhor prática e a pior prática. Deste ponto de vista sim existe o correto e o errado e são uma única coisa : o nivel de obediencia aos principios fundamentais.
Quanto a pessoa não conhece os principios fundamentais ou não vê como eles se relacionam com outras coisas ( padrões , por exemplo) ela não entende que a autoridade de uma melhor prática advêm de um pensamento, de um principio, e pensa -erradamente- que se trata de uma mera convenção; que as pessoas dicidiram fazer da forma X e fazer da forma X é melhor porque é o que a maioria aceita. Ora, isso não é verdade. A verdade é que se faz da forma X porque a forma X deriva de principios fundamentais. E não se faz da forma Y porque Y é uma violação aos principios fundamentais.
O conhecimento empirico é muito bom, mas é pior que o conhecimento teorico que lhe dá origem. Se uma pessoa tentar decorar todos os principios práticos ela será um bom desenvolvedor se os respeitar; mas se ela souber de onde eles derivam ela não terá que os decorar e poderá derivá-los sempre que necessário e conforme a circunstancia do ambiente onde os necessita.
É esta adapatabilidade que a teoria tem a produzir resultados ligeiramente dirernetes conforme o ambiente que o conhecimento empirico não tem.
Conhecer os principios e derivar as práticas é ciencia. Conhecer as práticas e ingorar os principios é superstição.
Sim existe o certo e sim existe o errado. O errado é não fazer o certo, e o certo é seguir os principios.
Aceite esta permissa básica sobra discutir a imutabilidade dos principios.
Os principios em si são imutáveis. o SoC sempre será o SoC. Mas o conjunto de principios aceites como “matriz primária” podem variar com o tempo e os costumes. Antigamente não se pensava em Objetos. Funções e rotinas eram o que havia de melhor.
Este conjunto de principios que aceitamos como “o conjunto básico” forma aquilo a que se chama o paradigma.
Portanto, paradigmas mudam, mas dentro de um paradigma é possivel estabelecer o que é certo e errado. quando o paradigma mudar, tlv uma acção que era certa vire errada e uma que era errada seja aceite como certa, mas será em outro paradigma.
A literatura simplesmente corre atrás das alterações de paradimga e da documentação das práticas ( boas e más) e da sua relação com os principios básicos. Contudo este é sempre um trabalho em andamento (work in progresss) e nunca pode ser tomada como a palavra final. Nunca.
A literatura serve para nos guiar, não para nos prender.
Sergio, vc varia do pragmatismo à rigidez numa velocidade incrível! Seu post foi muito filosófico e lendo a thread toda fica até confuso interpretar seu ponto de vista. Queria algumas respostas mais diretas suas às questões abaixo.
Já discutimos antes: http://www.guj.com.br/posts/list/90/85211.java
Posts atrás vc mencionou que para implementar DAO corretamente eu preciso de DTOs. Na discussão listada acima você falou que necessariamente a casadinha Repository/DAO necessita ser Strategy. Não quero reviver aquela discussão.
Você diz que os padrões são linguagem e para que eles estejam certos eles devem ser implementados como diz GOF, Fowler, Evans e etc…
Todos os padrões são classificados no tão fadado: Problema, Motivações, Solução, Estrutura e Exemplos. Até o momento você diz que se você não seguir ao menos a Estrutura não podemos dizer que estamos usando o padrão. Se eu tenho um problema (data mapping) que segue as motivações e se aproxima do padrão DAO mas não usa TO você poderia dizer que não estamos usando o padrão? Não poderemos chamar a classe de DAO?
Quando falamos DAO o que deveria vir a nossa mente: o problema e a solução ou a estrutura?
Outro ponto. Pelo que me lembro Core J2EE Patterns não deveria se aplicar a arquitetura mais modernas como EJB3, principalmente no acesso a dados JPA. Certo? Como devemos chamar então as classes que usam o EntityManager?
Pode, vc pode tudo. Dever vc não deve. Se vc não utiliza TO o seu DAO não é independente do dominio/negocio.
Se o seu problema e apenas o data mapping e vc resolve usar entidades como retorno e paramentro vc resolveu o seu problema.
Mas ao fazer isso vc criou outros problemas : dependencia. O que eu estou dizendo é : se quer resolver o problema , use o padrão certo. Se não quer ter mais problemas depois, implemente o padrão da forma certa. E a forma certa é, aquela que segue os principios de OO. Independencia (baixo acoplamento) é um deles.
O que é ou não um DAO tem a haver com: (por ordem de relevancia)
Para descobrir a responsabilidade vc precisa levar em conta outros fatores como o acoplamento, o tratamento de exceções, etc, etc… ou seja, vc precisa aplicar os conceitos e principios de OO.
Depois vc pensa na implementação. Ela é uma consequencia directa do passo 1 portanto é muito simples.
O que não pode ser feito, e é isso que muitos fazem , é começar pela implementação e chutar um nome para o objeto que não é coerente com a sua responsabilidade.
Se vc quer um atalho neste processo vc usa um padrão. Mas, embora existam ajustes que podemos fazer nas implementações do padrões ( por exemplo, um VO serializável é mais util do que um que não seja) o espirito do padrão - as responsabilidades do objeto - têm que ser respietadas. Se isso não acontecer não estamos seguindo o padrão. Estamos sendo inspirados (vagamente) pelo padrão. São coisas diferentes.
Aquilo que o padrão é, está nas responsabilidades dos objetos que ele propõe. Tudo o testo é consequencia directa de OO, de principios ou da sintaxe do java e seus construtos.
A responsabilidade de cada objeto envolvido no padrão.
No caso do DAO existem: a interface publica do DAO, os objetos passados ao DAO para que ele execute pesquisas, os objetos passadas ao DAO para que ele execute edições , os objetos retornados pelo DAO como resultado da consulta,
a implementação do DAO para a tecnologia X, a implementação para tecnologia Y, etc…
Esta coisas têm que ser tais que:
A opção 3 é boa se vc quer o seu DAO reutiliável. Se não quer, ignore-a. Contudo saiba que no proximo projeto vc vai implementar o DAO outra vez…
como vc consegue 2 sem usar objetos de transferencia ?
como vc consegue 2 e 3 sem usar objetos de transferencia ?
O uso de TO é a opção lógica pela simples aplicação dos requisitos do DAO.
Como eu já disse: se não quer ter um DAO reaproveitável utilize as entidades à vontade. (só não se queixe depois )
A segunda edição do Core Patterns tem muitas influencias do trabalho do Fowler e do Struts. É um remake, mas tem mais tempo de filme que antes. Algumas cenas foram incluidas como Domain Storage (que é o JPA).
Embora seja uma referencia o livro é muito versado em arquitetura web e ignora quase sempre outras arquiteturas, mas pelo menos para essa tá valendo ( a maior parte )
A arquitetura EJB 3 é apenas uma evolução da 2 onde mais padrões são providos pelo container. Mas o uso e entendimento dos padrões subjacentes é o mesmo. A diferença é que antigamente vc precisa construi-los à mão. Agora vc os tem no conteiner por default. Mas tal como antes tlv o default nao seja suficiente, e nesse caso os padrão ainda têm a sua importancia.
Se não for por mais nada, tem importancia historica e como catalogo.
Repositorio.
Pois é, se o livro que define o padrão chama, por que você não poderia?
Eu acho essa frase que o Phillip começou a falar aqui no forum corretíssima. O unico problema é que o pessoal ta se apegando nisso e começando a era do “Vale qualquer coisa já que não tem certo/errado” e distorcendo tudo conforme lhe apraz.
Quanto as respostas do sergiotaborda, já disse que não perco mais tempo me repetindo e o MarcioDuram, esse ai nem vale a pena.
Eu acho essa frase que o Phillip começou a falar aqui no forum corretíssima. O unico problema é que o pessoal ta se apegando nisso e começando a era do “Vale qualquer coisa já que não tem certo/errado” e distorcendo tudo conforme lhe apraz.
Mas essa é a a forma como as coisas evoluem, com questionamentos. Eu acho ótimo que as pessoas tenham idéias diferentes sobre as coisas, que discordem e achem besteira fazer do modo X e Y. O que não dá para engolir é alguém que diz que a sua versão do conceito/coisa é o CERTO e o que o autor do conceito/coisa escreveu é ERRADO. Eles são discordantes, só isso. Da discórdia pode até sair um conceito muito interessante, mas não adianta dizer que esse é o DTO como catalogado por Fowler, este é o DTO como catalogado pelo Joãozinho e ainda que o Joãozinho tenha razão -o que não necessariamente é verdade- ele precisa deixar claro que é um outro ponto de vista sobre o conceito.
Eu acho essa frase que o Phillip começou a falar aqui no forum corretíssima. O unico problema é que o pessoal ta se apegando nisso e começando a era do “Vale qualquer coisa já que não tem certo/errado” e distorcendo tudo conforme lhe apraz.
Mas essa é a a forma como as coisas evoluem, com questionamentos.
Exatamente. Estou totalmente de acordo com você. O problema todo é:
Isso realmente não dá pra engolir. Dai o motivo de toda irritação.
:idea: Direito de Resposta
Não estou nesse debate sobre DDD, entrentanto eu venho acompanhando o assunto com atenção das pessoas especializadas ou melhor entendida e posicionamento, quanto observadas as suas colocações, é lamentável por só tomar carona em pensamentos alheios, “tenha mais personalidade ou saiba só ouvir quem possa melhor dar explicações.”
Não há desculpa para não entender DDD, eu colocaria com existem milhares de questões a se projetar Patterns, não só se baseando em aspectos de autoria e referências apenas bibliograficas mas sim em requisitos que melhores vão ser projetados em seu Core de responsabilidades.
Eu acho essa frase que o Phillip começou a falar aqui no forum corretíssima. O unico problema é que o pessoal ta se apegando nisso e começando a era do “Vale qualquer coisa já que não tem certo/errado” e distorcendo tudo conforme lhe apraz.
Mas essa é a a forma como as coisas evoluem, com questionamentos.
Exatamente. Estou totalmente de acordo com você. O problema todo é:
Isso realmente não dá pra engolir. Dai o motivo de toda irritação.
Mas… dizer que o autor errou não é um questionamento ? Não é isso uma evolução ?
Afinal os criticos de Da Vinci , Darwin ,Hamilton, Eisntein , etc devem ser todos amordaçados e deixados sem palavra?
Afinal o submarino, a asa delta , o helicóptero e o avião existem porque alguem leu o trabalho de Da Vinci mas o colocou em causa. Aproveitou a essência e reescreveu a concretização
O mesmo para a moderna teoria da evolução baseada no DNA. ninguém mais dá crédito ao que Darwin escreveu em seus diários, mas a essência do que ele escreveu - que existia uma evolução natural - foi aproveitada. As regras dessa evolução foram reescritas várias vezes ao longo do século. O mesmo para o trabalho de Hamilton sobre Quaterniões: um construto matemático tão poderoso que resume o eletromagnetismo a uma equação (e não 4), mas que, pela sua complexidade não é usado. Mas qualquer matemática os aceita e entende o que é um quaternião e até são usados em animação 3D. O mesmo para o trabalho de Einstein. Todos os que o colocaram em causa encontraram outras formas de ver as coisas. E mesmo com a sua fama e grande contribuição para o conhecimento humano ainda é ridicularizado (infamemente) pela citação errada da frase “Deus não joga aos dados” quando a frase completa é :" Não acredito que o Grande Arquiteto criasse um universo como o da Mecânica Quantica, não acredito que ele jogue os dados"
Isto é para ilustrar a falha em endeusar os autores. Criam-se mitos e inverdades que apenas atrapalham o desenvolvimento do conhecimento com um todo. Autores são pessoas normais, também erram. Não aceitar isso é viver em uma utopia.
Sim, os autores escrevem coisas que vão contra as normas , os modelos , as teorias : os paradigmas subseqüentes, mesmo quando o trabalho deles deu origem a esse paradigma. Pioneiros são mais suscetíveis de ter esses problemas, porque embora tenham tido a inspiração ( insign) que dá origem ao paradigma, nenhum homem é capaz de explorar um novo paradigma sozinho. À media que ele é explorado por outros, e à medida que ha documentação do paradigma, essa documentação está votada a ficar desatualizada em algum tempo. O tempo em que ela permanece válida depende do tempo em que o paradigma permanece inalterado. A idade média na europa viveu um período negro porque muitos se recusavam a abandonar o paradigma teocrático/monárquico que existia. Quando isso aconteceu muitos morreram pela mesma insensatez e irritação que o Emerson diz sentir. Nada bom advém dai. Foram necessários séculos e muito esforço para mudar as coisas.
Podem espernear o quanto quiserem. Rogar quantas pragas quiserem. Ridicularizar o quanto quiserem. Mas nunca será aceitável dizer que um autor é dono da verdade absoluta e o que ele disse ou escreveu é irrevogável, imutável ou indiscutivel. Isso é nada mais, nada menos, que pertencer a uma inquisição e executar censura. Nunca aceitarei participar disso e ninguém neste fórum deveria.
Se ha argumentos, ha argumentos. Se não ha argumentos, é melhor ficar calado. Demonstrações de censura, ataques pessoais, ridicularizações publicas , e todas essas armas comuns de quem vive no passado , preso a texto antigos , são ações completamente vãs e apenas servem para demérito deste forum.
Irrite-se o quanto quiser, mas pelas coisas que valem a pena.
Por outro lado, quem não compreende um simples texto de português não pode ficar irritado com coisa nenhuma até entender o que foi escrito. Análise e síntese, duas ferramentas vitais que infelizmente quase ninguém neste forum sabe usar. Antes de ficarem irritados ou ridicularizarem os participantes , ou até censurarem o que é dito, pensem em utilizar essa ferramentas e entender os assuntos. Enquanto não conseguirem, optem por ficar calados como faz a grande maioria de usuários deste forum. Observar é uma virtude muito melhor que a irritação.
Acho que vou pedir revisão dos pontos perdidos em todas as provas de interpretação de texto que fiz na minha vida, pois afinal de contas, eu tinha o direito de interpretar diferente do professor. Tentar entender a idéia do autor? não faz o menor sentido, melhor ficar com a minha. :shock:
Sobre essa questão de DAOs com DTOs, posso até concordar que o Core J2EE Patterns apresentou o uso daquele em conjunto com este. Mas isso era considerado boa prática quando sistemas J2EE eram modelados em termos de BOs e TOs; hoje em dia, onde somos tão estimulados a manter dados e comportamento em uma só entidade, IMHO não há justificativa em criar TOs apenas para utilizar o DAO da forma como veio ao mundo.