Entendendo o Repository Pattern
Hoje venho apresentar o Repository Pattern, um dos padrões de projeto mais utilizado e conhecidos no desenvolvimento de sistemas. Sua utilização contribui no isolamento da camada de acesso a dados (DAL) com a camada de negócio, mais conhecida como camada de domínio.
O Repository Pattern permite um encapsulamento da lógica de acesso a dados, impulsionando o uso da injeção de dependencia (DI) e proporcionando uma visão mais orientada a objetos das interações com a DAL.
Com o uso desse pattern, aplicamos em nossa camada de domínio o princípio da persistência ignorante (PI), ou seja, nossas entidades da camada de negócio, não devem sofrer impactos pela forma em que são persistidas no banco de dados.
Os grandes benefícos ao utilizar esse pattern são:
- Permitir a troca do banco de dados utilizado sem afetar o sistema como um todo.
- Código centralizado em um único ponto, evitando duplicidade.
- Facilita a implementação de testes unitários.
- Diminui o acoplamento entre classes.
- Padronização de códigos e serviços.
Existem diversas formas de implementação, porém neste post, abordaremos os repositórios genéricos e repositórios especializados.
Vamos a implementação…
Antes de tudo, vamos definir nossa entidade de forma bem simples, conforme segue abaixo
Começamos pela implementação do repositório especializado. Vamos definir uma interface contendo algumas funções que deverão executados em nossa DAL, lembrando que essa interface atuará como uma fachada.
Note que em alguns retornos e parâmetros utilizamos nossa entidade “Client”, portanto, as funções executadas na DAL por esse repositório, são referentes a entidade “Client” somente.
Utilizando os repositórios especializados, necessitamos criar uma interface para cada entidade da camada de negócio. É um trabalho exaustivo e repetitivo, porém temos todas as nossas interfaces especialistas definidas, facilitando futuras manutenções, padronizando e organizando a estrutura do nosso projeto.
Acima foi criado um repositório para Cliente, porém podemos ter vários outros para Produtos, Categoria, Vendas, entre outros.
Agora que vimos sobre o repositório especialista, vamos implementar nosso repositório genérico, conforme segue abaixo:
As entidades genéricas, como o próprio nome explica, podem ser utilizadas por qualquer entidade da nossa camada de negócios, portanto, com seu uso, diminuimos a quantidade de código escrito.
Porém, como para tudo é necessário uma análise antecipada, com os repositórios genéricos não é diferente. Cada entidade da nossa camada de domínio possui suas particularidades distintas de outras entidades, deixando o uso de repositórios genéricos inviável.
Mas por quê inviável?
Ao utilizarmos os repositórios genéricos, assumimos que cada entidade possui as mesmas características e os mesmos comportamentos, porém, como já sabemos, é um grande equívoco assumir isso.
Continuando a implementação, após a definição da interface, vamos utilizá-las para a implementação do nosso repositório. Abaixo, temos a implementação
Na classe acima, implementamos a nossa interface, tornando obrigatória a implementação dos métodos existentes na interface.
Nos métodos devemos realizar a implementação da lógica de acesso a dados. Para nos auxiliar na leitura e persistência, temos alguns ORM disponíveis no mercado, como o NHibernate, Entity Framework, como também podemos utilizar um micro ORM. Nesse caso o mais conhecido e adotado é o Dapper.
Acima, acabamos de implementar nosso Repository Pattern, portanto, sempre que necessitarmos de alguma leitura ou persistência de dados, devemos utilizar nossa interface.
O projeto de exemplo pode ser encontrado em meu github https://github.com/reniciuspagotto/RepositoryPattern
Até mais!
