apresentação: padrões de projetos para persistência de dados
DESCRIPTION
Apresentação para o trabalho de PDS. UFCTRANSCRIPT
Padrões de Projeto para Persistência de Dados
Luan Pereira Lima e Randerson Lessa Melo
Introdução
● Armazenamento não volátil de dados.● Manter em meio físico recuperável:
○ Banco de dados.○ Arquivos.
Motivação
Existem muitas maneiras de persistir dados ou estruturas de dados.
Motivação
Mas qual é o melhor padrão pra usar em seu projeto?
Motivação
Quais os critérios que você deve usar para selecionar o melhor padrão para seu projeto?
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.
Motivação
Mas sim, utilizar padrões! Para assim estabelecer locais na aplicação adequados.
Camadas
Disciplinam o fluxo de mensagens entre certos tipos de classes.
Entendendo
Camadas
O Modelo de Camadas provê uma forma de se estruturar as classes com propósitos semelhantes, ou seja, agrupar em
uma mesma camada.
Camadas
Dentro de uma camada, a troca de mensagens entre suas classes pode ocorrer livremente.
CamadasModelo
CamadasInterface
● 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.
CamadasNegó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.
CamadasPersistê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.
CamadasSistema
● Fornece acesso aos recursos do sistema.
Exemplos de Padrões● Active Record● DAO (Data Access Object)● Data Mapper● Repository
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.
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.
PadrãoActive Record
O próprio objeto implementa métodos como Salvar, Restaurar, Filtrar e etc.
PadrãoActive Record
Modelo
PadrãoActive Record
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.
Problemas
PadrãoActive Record
Classes enormes, e que retém muita responsabilidade.
Problemas
PadrãoActive Record
Problemas
Utilização em sistemas pequenos, com baixo nível de complexidade.
PadrãoDAO (Data access object)
A princípio é que para cada Modelo, temos um DAO correspondente.
PadrãoDAO (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.
PadrãoDAO (Data access object)
Passa a programar métodos como Select, Delete, Insert, Update.
PadrãoDAO (Data access object)
Pode-se programar métodos mais específicos, como selecioneNomeComLetraTal()
ou cadastrarFulano().
PadrãoDAO (Data access object)
Modelo
PadrãoDAO (Data access object)
Utilização em sistemas pequenos, com nível baixo de complexidade.
Problemas
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
Data Mapper
Os objetos de memória não precisam saber ainda que há um presente banco de dados.
Padrão
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
Data MapperPadrão
Modelo
Data Mapper
Pequena comunidade, pouca documentação.
PadrãoProblemas
PadrãoRepository
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.
Padrão
Pertencem a camada de aplicação, junto aos modelos.
Repository
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
Padrão
É ai que os DAOs vão atuar, os Repositórios vão delegar as chamadas aos DAOs.
Repository
Padrão
Os DAOs vão atuar implementando as chamadas mais genéricas, select, insert, update e delete.
Repository
PadrãoRepository
Modelo
Padrão
Grande número de classes criadas na aplicação.
Repository
Problemas
Conclusão
Não existe uma receita.
Conclusão
Todo projeto tem seus próprios problemas e exigem suas próprias soluções.
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.
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-patternhttp://manifesto.blog.br/2.0/Programacao/dao-active-record
➢ Padrão de projeto de softwarehttps://www.ime.usp.br/~kon/MAC5715/PLoP/2006/refact/RoupaSujaSeLavaEmCasa-ref.pdf
➢ Persistence Patterns, Jeremy Millerhttp://msdn.microsoft.com/en-us/magazine/dd569757.aspx
➢ [email protected]➢ [email protected]➢ Professor: Camilo Camilo Almendra