O objetivo deste bog, não é mostrar como criar a codificação de um repository parttner ou service parttner, mas sim o conceito de forma breve e direta.
REPOSITORY
Martin Fowler define um repositório como:
Um Repositório faz a mediação entre o domínio e as camadas de mapeamento de dados, agindo como uma coleção de objetos de domínio na memória. Objetos de cliente constroem especificações de consulta de forma declarativa e as enviam ao Repositório para satisfação. Objetos podem ser adicionados e removidos do Repositório, assim como de uma simples coleção de objetos, e o código de mapeamento encapsulado pelo Repositório realizará as operações apropriadas nos bastidores.
Conceitualmente, um Repositório encapsula o conjunto de objetos persistidos em um armazenamento de dados e as operações realizadas sobre eles, fornecendo uma visão mais orientada a objetos da camada de persistência. O repositório também suporta o objetivo de alcançar uma separação clara e dependência unidirecional entre as camadas de mapeamento de domínio e de dados.
Um padrão de repositório é um padrão de design que medeia dados de e para o domínio e as camadas de acesso a dados (como Entity Framework Core / Dapper). Repositórios são classes que ocultam as lógicas necessárias para armazenar ou recuperar dados. Assim, nossa aplicação não se importará com o tipo de ORM que estamos usando, pois tudo relacionado ao ORM é tratado dentro de uma camada de repositório. Isso permite que você tenha uma separação mais limpa de preocupações. O padrão de repositório é um dos padrões de design mais usados para criar soluções mais limpas.
O padrão Repository, nos permite criar uma camada de abstração entre o acesso aos dados e a camada de lógica de negócios de uma aplicação. Ao usá-lo, estamos promovendo uma abordagem mais flexível para acessar nossos dados do banco de dados. Além disso, o código é mais limpo e mais fácil de manter e reutilizar. A lógica de acesso a dados está em uma classe separada, ou conjuntos de classes chamados de repositório, com a responsabilidade de persistir o modelo de negócios do aplicativo.
Observe, o argumento é fraco, mas não irreal, como foi muito bem ressaltado por Shawn McCool
“Any sufficiently designed object-oriented application automatically comes with this type of advantage. A very central concept to object-orientation is encapsulation. You can expose an API and hide implementation”
Em outras palavras, o que ele defende é que esse não deve ser o motivo real para a utilização / aplicação do padrão em seus projetos, já que a troca de ORM não acontece assim… num estalar de dedos… e o encapsulamento está ai pra facilitar essa troca, quando esta necessidade realmente existir.
Quando utilizar Repository Pattern
Não podemos afirmar sobre o assunto. Mas pode ser usado quando desejar deixar as coisas mais organizadas e separadas e criar uma barreira (de controle e segurança) entre a aplicação e os seus dados, utilize repositórios. Mas, caso o projeto não necessite usar, não use, pois somente irá irão gerar desperdícios (de tempo, esforço, etc).
Repositório é um serviço de domínio ou de aplicação?
Repositório é ser um serviço de domínio, que abstrai a camada de persistência da sua aplicação e atua como API para os serviços de aplicação (controllers, CLI, etc). Ou seja, deve ser a única API de acesso confiável aos objetos de domínio e não deve ser responsável por conexões ao banco, envio de e-mail, etc…
Benefícios
- Reduz consultas duplicadas
- Desacopla o aplicativo da camada de acesso a dados
O Padrão Do Repositório Está Morto?
Este é um dos tópicos mais debatidos na comunidade .NET Core. A Microsoft construiu o Entity Framework Core usando o Repository Pattern e Unit of Work Patterns. Então, por que precisamos adicionar outra camada de abstração sobre o Entity Framework Core, que é mais uma abstração do Data Access. A resposta para isso também é dada pela Microsoft.
A própria Microsoft recomenda (conselhor, aviso, advertir) o uso de Repository Patterns em cenários complexos para reduzir o acoplamento e fornecer melhor Testabilidade de suas soluções. Nos casos em que você deseja o código mais simples possível, deve-se evitar o Repository Pattern.
SERVICES
A ideia básica é a seguinte:
- Um usuário envia uma solicitação HTTP para o servidor.
- O Asp.Net MVC roteia a solicitação para uma Controlleração.
- A responsabilidade da ação é lidar com a solicitação e a resposta, nada mais.
- Como a lógica do domínio não é de responsabilidade do controlador, ela deve ser delegada a outro objeto. Esse objeto é o Service.
- Embora Servicepossua a responsabilidade da lógica do domínio , ele não pode assumir outra, portanto, não pode lidar com a lógica de acesso aos dados . Deve delegar isso ao Repository.
- O Repository, como já dito, é o responsável pelo acesso aos dados. Basicamente, ele lê/grava dados de/para uma fonte de dados .
As classes Service são projetadas para fazer duas coisas:
- Consultar um ou mais repositórios e
- Implementar sua própria funcionalidade, o que é útil quando essa funcionalidade lida com mais de um objeto de negócio.
O padrão Repository-Service divide a camada de negócios do aplicativo em duas camadas distintas.
- A camada inferior são os Repositórios . Essas classes lidam com a entrada e saída de dados de nosso armazenamento de dados, com a importante ressalva de que cada Repositório só funciona em uma única classe Model. Portanto, se seus modelos forem Dogs, Cats e Rats, você teria um Repository para cada um, o DogRepository não chamaria nada no CatRepository e assim por diante.
- Se temos dois modelos de negócios, precisamos de dois repositórios. Mas precisaremos ter as interfaces
- A camada superior são os Serviços . Essas classes terão Repositories injetados nelas e podem consultar várias classes Repository e combinar seus dados para formar objetos de negócios novos e mais complexos. Além disso, eles introduzem uma camada de abstração entre o aplicativo da Web e os Repositórios para que eles possam mudar de forma mais independente.
O padrão Repository-Service depende da injeção de dependência para funcionar corretamente. As classes em cada camada da arquitetura terão classes de que precisam das camadas "inferiores" injetadas nelas.
Portanto, nossas classes Service serão classes simples de "passagem" para retornar as informações em seus respectivos repositórios.
Por último a Controller fará a Injeção de Dependência da classe de serviços.
Resumo
O Repository-Service Pattern é uma ótima maneira de arquitetar um aplicativo complexo do mundo real. Cada uma das camadas (Repositório e Serviço) tem um conjunto bem definido de preocupações e habilidades e, mantendo as camadas separadas, podemos criar uma arquitetura de programa de fácil modificação e manutenção.
Um forte abraço a todos e até a próxima
