Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Fala, galera!
Indo direto ao ponto, qual a diferença entre o padrão de software DAO e um ORM?
Em minha ignorância, me parecem conceitos semelhantes, sendo o DAO simplesmente algo mais abstrato, então, de certa forma, me parece que todo ORM está implementando um DAO de qualquer maneira, uma vez que (sendo um DataMapper), separa a lógica de domínio, da lógica de acesso aos dados.
Agradeço desde já a contribuição com os meus estudos.
Olá, Gabriel!
Muito obrigada pela sua explicação bem detalhada sobre o tema, isso me ajudou muito.
Fazendo mais duas pergunta, se me permite:
Implementando em sua totalidade o padrão DataMapper, conforme descrito por Fowler, para realizar a conversão dos tipos relacional-objeto, eu estou, de algum modo, fazendo uso da técnica ORM, certo?
No DataMapper, eu implementaria o padrão DAO como uma camada mais baixa (o que me parece redundante numa aplicação pequena), ou o próprio padrão dispensa essa necessidade ao já estabelecer essa separação entre modelo de domínio/persistência de dados?
Agradeço imensamente suas respostas!
>
1 hora atrás, claudiojuniorfabiao disse:
Implementando em sua totalidade o padrão DataMapper, conforme descrito por Fowler, para realizar a conversão dos tipos relacional-objeto, eu estou, de algum modo, fazendo uso da técnica ORM, certo?
ORM é mais voltado para uma conversão automática. Como, por exemplo, o Doctrine o faz. Você mapeia os dados do objeto para o que seria sua representação no storage e o Doctrine realiza o restante. O DataMapper, por outro lado, é o seu mapeamento manual entre objetos e o storage. Mas o resultado é bastante similar.
>
1 hora atrás, claudiojuniorfabiao disse:
No DataMapper, eu implementaria o padrão DAO como uma camada mais baixa (o que me parece redundante numa aplicação pequena), ou o próprio padrão dispensa essa necessidade ao já estabelecer essa separação entre modelo de domínio/persistência de dados?
O próprio padrão dispensa a necessidade. Se quiser visualizar um pouco sobre o padrão, olhe olhar no link abaixo:
http://blog.tekerson.com/2008/12/17/data-mapper-pattern-in-php/
Apenas para ressaltar, a implementação no link acima é bem básica. Você poderá encontrar uma implementação bem completa no livro "PHP Objects, Patterns, and Practice" do Matt Zandstra.
>
13 minutos atrás, Gabriel Heming disse:
ORM é mais voltado para uma conversão automática. Como, por exemplo, o Doctrine o faz. Você mapeia os dados do objeto para o que seria sua representação no storage e o Doctrine realiza o restante. O DataMapper, por outro lado, é o seu mapeamento manual entre objetos e o storage. Mas o resultado é bastante similar.
O próprio padrão dispensa a necessidade. Se quiser visualizar um pouco sobre o padrão, olhe olhar no link abaixo:
http://blog.tekerson.com/2008/12/17/data-mapper-pattern-in-php/
Apenas para ressaltar, a implementação no link acima é bem básica. Você poderá encontrar uma implementação bem completa no livro "PHP Objects, Patterns, and Practice" do Matt Zandstra.
Ah, valeu mesmo, cara!
Isso realmente me ajudou muito, eram exatamente as informações que eu estava precisando.
Novamente, muito obrigado!
A maioria dos padrões de persistência são similares, com apenas algumas modificações.
ORM é definido como uma técnica de conversão de dados entre sistemas incompatíveis, como o modelo orientado à objetos e o modelo relacional.
DAO é utilizado para abstrair e encapsular todo o acesso ao data source (fonte de dados). Dessa forma, o sistema pode mudar de data source sem se preocupar com o sistema em si, apenas com o DAO.
DataMapper, conceitualmente, é semelhante ao DAO, entretanto, é um conjunto de camadas que move os dados entre objetos e o storage, mantendo a independência entre os objetos e o mapper em si.
Apesar dos conceitos serem semelhantes, a prática se torna diferente. O DAO acaba se tornando uma relação bem direta entre objetos e o banco de dados, quase culminando entre uma tabela se tornar um objeto (o que não é regra). No final das contas, o DAO acaba sendo apenas uma camada intermediária entre o sistema e o storage.
Por outro lado, o DataMapper, mapeia o modelo orientado à objeto para o modelo relacional. Dessa forma, não é raro que um objeto possa se tornar mais de uma tabela no banco de dados e vice-versa, como é o caso do relacionamento N:M que exige, no modelo relacional, uma tabela intermediária. Essa exigência não é necessária no modelo orientado à objetos.
No final das contas, o DataMapper possui uma alta abstração e alta granularidade, necessitando a implementação de diversos participantes (Mapper, Factory, Collection, Entity, UnitOfWork, IdentityMap). Já o DAO, pode ser implementado apenas utilizando duas camadas, o DAO em si e a entidade (Entity).
Ambos os padrões DAO e DataMapper não são diretamente relacionados ao ORM. O ORM pode utilizar algum desses padrões, não sendo uma obrigatoriedade e nem precisa utilizá-lo por completo.
Outro padrão exitente é o TableDataGateway, o qual você pode ler no artigo do Henrique Barcelos:
https://imasters.com.br/linguagens/php/padroes-tabledatagateway-e-tablerowgateway-teoria-e-pratica/
No final das contas, mesmo com suas semelhanças/diferenças, cada padrão vai lhe entregar o que se propõe com seus prós e contras. Cabe a você decidir o que irá escolher.