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.
[/quote]
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!!!
[quote]
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]
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.
[quote=luiz_ross]
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.[/quote]
É verdade. Isso chama-se texlexia, não é de propósito… mea culpa.
[quote=Paulo Silveira][quote=sergiotaborda]
…
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.
…
[/quote]
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.
[/quote]
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:
Sergio,
Até onde eu sabia era isso que o Shoes passou.
…finalmente tem alguma diferença entre DTO e TO ?
[/quote]
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.
[quote=sergiotaborda]
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. [/quote]
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.
[quote=Emerson Macedo][quote=sergiotaborda]
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. [/quote]
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.[/quote]
Você acha demasiadas coisas de mim … :shock:
Eu só leio livros tecnicos dessa importância em ingles.
[quote=sergiotaborda]
Você achas demasiadas coisas de mim … :shock:
Eu só leio livros tecnicos dessa importância em ingles. [/quote]
Então me desculpe, pois já que você leu em inglês, deve ter lido esse trecho do livro sobre o Pattern TO:
[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.[/quote]
Mas como não adianta nada postar as referências, mesmo que completas, eu desisto de discutir isso com você.
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.
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)
[quote=Emerson Macedo]
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 ?
[quote=Emerson Macedo][quote=sergiotaborda]
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. [/quote]
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.[/quote]
:idea: Emerson, como você tem dificuldades sérias de entender as coisas, ainda bem que as pessoas aqui tem paciência com você …
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í.
[quote=Lezinho][code]
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();
}
}
[/code][/quote]
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:
interface DAO<T> {
void add(T t);
void update(T t);
void delete(T t);
void find(String query, Object[] parameters);
}
Veja que este DAO ficou ligeiramente acoplado com JDBC (Object[] parameters, passado para o PreparedStatement). Não consegui remover essa dependência.
De qualquer forma, em um semestre próximo vamos usar o mesmo projeto e modificar a persistência para Hibernate. Tudo o que eu vou precisar fazer é escrever novas implementações dos meus repositórios que utilizem um objeto Session do Hibernate.
