Ouvi muito do padrão de repositório, mas não entendi o que um repositório deveria realmente fazer. Quando digo "o que um repositório realmente deve fazer", estou preocupado principalmente com quais métodos ele deve fornecer. Por exemplo, um repositório deve realmente fornecer métodos CRUD, ou deve fornecer algum tipo diferente de método?
Quero dizer, os repositórios devem conter lógica de negócios ou devem simplesmente conter a lógica para se comunicar com o armazenamento de dados e gerenciar as entidades a serem salvas ou carregadas?
Também ouvi dizer que repositórios são unidades de persistência para agregados. Mas como é isso? Não entendo como isso funciona na prática. Eu pensei que deveríamos ter apenas uma interface IRepository
que contenha os métodos CRUD e, para qualquer entidade, a implementação simplesmente conteria a lógica para salvar e recuperar esse tipo do armazenamento de dados.
fonte
Respostas:
Bem, você pode ver um bom exemplo no Spring Data Framework, que é baseado no conceito de repositórios.
Lá você verá repositórios que lidam apenas com o armazenamento de dados e raramente contêm lógica comercial (isso é reservado para a camada de serviço). Então, por exemplo, dê uma olhada no design deles e verá que eles têm uma interface CRUDRepository que expõe métodos para criar, destruir e recuperar entidades (entre outras coisas). Há também um PagingAndSortingRepository que adiciona funcionalidade extra para exatamente isso, resultados de classificação e paginação, etc., etc.
Portanto, essa estrutura é talvez um bom lugar para estudar um bom design de repositório.
Até onde eu sei, muitos dos conceitos implementados pelo Spring Data Framework vêm de um ótimo livro chamado Design Orientado a Domínio: Combatendo a Complexidade no Coração do Software , o livro tem uma seção inteira dedicada ao design do Repositório.
Você pode obter uma cópia dele.
Um pequeno trecho do livro explica:
fonte
Ele não deve fornecer uma interface CRUD direta nem lógica de negócios. Ele medeia entre a lógica de negócios e o banco de dados. A interface deve estar em termos de lógica de negócios, mas não executar a própria lógica de negócios, mais como uma primitiva de lógica de negócios. Como exemplo, digamos que você iria construir um sistema de email, você tem usuários e mensagens. Seu repositório forneceria operações CRUD básicas para usuários e mensagens, mas também forneceria visualizações filtradas de mensagens como GetUsersNewMessages (usuário) ou GetSearchedMessages (usuário, searchTerms).
A idéia é que o Repositório oculte como o armazenamento é implementado e forneça uma interface limpa que permita acesso rápido e flexível aos dados. Manter as operações em termos de alto nível do que deveria acontecer e não de como significa que você tem mais flexibilidade para implementá-las da melhor maneira para o armazenamento subjacente.
fonte