O documento discute padrões para persistência de dados, incluindo Active Record, DAO, Data Mapper e Repository. Cada padrão organiza de maneira diferente as responsabilidades de acesso e mapeamento de dados. O documento conclui que não existe uma solução única e a escolha de padrão deve considerar as necessidades de cada projeto.

1. Padrões de Projeto para
Persistência de Dados
Luan Pereira Lima e Randerson Lessa Melo

2. Introdução
● Armazenamento não volátil de dados.
● Manter em meio físico recuperável:
○ Banco de dados.
○ Arquivos.

3. Motivação
Existem muitas maneiras de persistir dados ou estruturas de
dados.

4. Motivação
Mas qual é o melhor padrão pra usar em seu projeto?

5. Motivação
Quais os critérios que você deve usar para selecionar o
melhor padrão para seu projeto?

6. Motivação
Quando se quer ter dados persistidos, a melhor maneira
não é colocar as conexões com bancos ou arquivos em
qualquer parte do sistema.

7. Motivação
Mas sim, utilizar padrões! Para assim estabelecer locais na
aplicação adequados.

8. Camadas
Disciplinam o fluxo de mensagens entre certos tipos de
classes.
Entendendo

9. Camadas
O Modelo de Camadas provê uma forma de se estruturar as
classes com propósitos semelhantes, ou seja, agrupar em
uma mesma camada.

10. Camadas
Dentro de uma camada, a troca de mensagens entre suas
classes pode ocorrer livremente.

11. Camadas Modelo

12. Camadas Interface
● Propósito de interação com o usuário.
● Mensagens fluem desta camada para a de negócios.
● Mudanças na interface não afetam a camada de
negócios.

13. Camadas Negócio
● Modelam o domínio de problema.
● Encapsula as funcionalidades da aplicação, sem se
preocupar com interfaces de usuário e a persistência de
dados.

14. Camadas Persistência
● Agrupa classes que prover criação, remoção, alteração e
recuperação de dados persistentes.
● É um front-end que empacota o acesso ao mecanismo
de persistência.

15. Camadas Sistema
● Fornece acesso aos recursos do sistema.

16. Exemplos de Padrões
● Active Record
● DAO (Data Access Object)
● Data Mapper
● Repository

17. PadrãoActive Record
"Invade" a camada do Modelo/Domínio da aplicação,
definindo que um Objeto do modelo é o reflexo de uma
"linha" do banco de dados ou linhas de um arquivo.

18. PadrãoActive Record
Objetos que necessitam ser persistentes precisam
estender/implementar uma classe ou interface que tenha os
métodos equivalentes a uma linha do banco de dados.

19. PadrãoActive Record
O próprio objeto implementa métodos como Salvar,
Restaurar, Filtrar e etc.

20. PadrãoActive Record
Modelo

21. PadrãoActive Record
Problemas
Essa abordagem é muitas vezes considerada uma
falha no design da aplicação, pelo fato de que o
Domínio passa a ser subordinado do Banco de dados.

22. PadrãoActive Record
Problemas
Classes enormes, e que retém muita responsabilidade.

23. PadrãoActive Record
Problemas
Utilização em sistemas pequenos, com baixo nível de
complexidade.

24. Padrão DAO (Data access object)
A princípio é que para cada Modelo, temos um DAO
correspondente.

25. Padrão DAO (Data access object)
Toda interação e configuração com o Banco de dados,
ou com o framework de persistência, ficam na camada
dos DAO.

26. Padrão DAO (Data access object)
Passa a programar métodos como Select, Delete, Insert,
Update.

27. Padrão DAO (Data access object)
Pode-se programar métodos mais específicos, como
selecioneNomeComLetraTal()
ou cadastrarFulano().

28. Padrão DAO (Data access object)
Modelo

29. Padrão DAO (Data access object)
Utilização em sistemas pequenos, com nível baixo de
complexidade.
Problemas

30. Data Mapper
Separa os objetos de memória do banco de dados. A sua
responsabilidade é a transferência de dados entre os dois e
também para isolá-los um do outro.
Padrão

31. Data Mapper
Os objetos de memória não precisam saber ainda que há
um presente banco de dados.
Padrão

32. Data Mapper
A diferença entre o DAO é que este padrão muitas vezes
necessita de um framework para trabalhar, pois assim pode
ser usado seus mapeamentos relacionados a tabela do
banco de dados.
Padrão

33. Data Mapper Padrão
Modelo

34. Padrão Problemas
Data Mapper
Pequena comunidade, pouca documentação.

35. Padrão Repository
Camada de negócio da aplicação, responsável por
manter e persistir os objetos de Modelo, enquanto isto
não envolver a infra-estrutura de persistência.

36. Padrão
Repository
Pertencem a camada de aplicação, junto aos modelos.

37. Padrão
Sendo parte do modelo, os repositórios não conhecem
detalhes de infra-estrutura da aplicação (banco de
dados, http, etc)
Repository

38. Padrão
Repository
É ai que os DAOs vão atuar, os Repositórios vão
delegar as chamadas aos DAOs.

39. Padrão
Repository
Os DAOs vão atuar implementando as chamadas mais
genéricas, select, insert, update e delete.

40. Padrão Repository
Modelo

41. Padrão
Repository
Grande número de classes criadas na aplicação.
Problemas

42. Conclusão
Não existe uma receita.

43. Conclusão
Todo projeto tem seus próprios problemas e exigem suas
próprias soluções.

44. Conclusão
Na verdade existem formas que auxiliam na decisão do seu
projeto (designer), cabe a equipe identificar qual o melhor
padrão para a sua aplicação.

45. Referências
➢ Professora Kessia Aline Marques Ferreira
http://pt.slideshare.net/brenovit/modelo-de-camadas
➢ Um Manifesto, Programação, web, banco de dados e muito desenvolvimento.
http://manifesto.blog.br/2.0/Programacao/repository-pattern
http://manifesto.blog.br/2.0/Programacao/dao-active-record
➢ Padrão de projeto de software
https://www.ime.usp.br/~kon/MAC5715/PLoP/2006/refact/RoupaSujaSeLavaEmCasa-ref.pdf
➢ Persistence Patterns, Jeremy Miller
http://msdn.microsoft.com/en-us/magazine/dd569757.aspx
➢ luan_pereira_lima@hotmail.com
➢ randerson.lessa.melo@gmail.com
➢ Professor: Camilo Camilo Almendra