Foto de Daniel McCullough na Unsplash
Mesclar a lógica de acesso aos dados com as regras de negócio da aplicação não é uma boa idéia. Esse alto acoplamento torna a aplicação difícil de ser testada e estendida, mais suscetível a erros e mais difícil de ser mantida. Vamos resolver esse problema com o Repository Pattern!
Veja o seguinte exemplo:
Repare que esse código possui alguns problemas:
As regras de negócio não podem ser testadas sem a necessidade de dependências externas como o banco de dados, o que dificulta a criação de testes unitários para as regras de negócio;
Duplicação de código em toda a camada de negócio, o que dificulta a manutenção podendo gerar inúmeros bugs;
A medida que novas regras são adicionadas, o código tende a se tornar macarrônico, como uma classe que faz tudo sozinha;
Precisamos sempre nos atentar a manter o código limpo e evitar essa forma de alto acoplamento.
Por isso que existe o design pattern chamado Repository Pattern. O design pattern Repository é uma técnica usada para separar a lógica de acesso a dados da lógica de negócios. Ele fornece uma camada intermediária entre a camada de dados e a camada de aplicação, permitindo que a lógica de acesso a dados seja isolada e abstraída. Isso permite que a lógica de negócios seja reutilizada e testada independentemente da fonte de dados.
Como mencionado no livro “Clean Architecture” de Robert C. Martin:
“Uma arquitetura limpa tem várias camadas. Cada camada fornece serviços para a camada imediatamente acima dela. Nenhuma camada fornece serviços para a camada imediatamente abaixo dela. Isso cria uma série de abstrações que podem ser usadas para dividir as responsabilidades dentro de um sistema de forma clara e coerente. Uma dessas abstrações é o repositório.”
O uso do Repository pattern é um exemplo concreto de como aplicar essa abstração de forma a separar a lógica de acesso a dados da lógica de negócios, tornando o código mais fácil de entender, manter e testar, e permitindo flexibilidade para mudar a fonte de dados sem afetar a lógica de negócios.
Vamos refatorar o nosso código aplicando o Repository pattern:
Assim melhor isolamos as regras de negócio da infraestrutura, tornando o código mais limpo, mais testável, menos frágil e flexível, pra citar apenas alguns dos benefícios.
Essa implementação adere bem aos princípios do SOLID, mas isso fica para um outro artigo.
Espero que tenha feito sentido! Inté!