Benefícios do padrão de repositório: por que devemos considerá-lo
Ontem, dei uma cartilha sobre o padrão de repositório. Resumindo, é um daqueles padrões que eu acho que qualquer um que trabalhe em middleware construído em cima do WordPress deveria entender.
Ao dar uma cartilha em um padrão como este, pode ser difícil fazer justiça ao padrão quando você precisa:
- apresentá-lo,
- explicar como funciona,
- cobrir os benefícios,
- e dê uma pequena demonstração.
Mas a vantagem real do repositório não está apenas em abstrair a camada de dados do resto do aplicativo, mas também no fato de que ela pode (ou deve) ser facilmente trocada por vários armazenamentos de dados sem alterar a API.
Por exemplo, em uma instância, você pode precisar recuperar dados do banco de dados do WordPress, em outros casos você pode precisar recuperar algo de uma API de terceiros, ou talvez haja algum outro lugar do qual você precise recuperar dados.
Independentemente disso, a ideia por trás do padrão de repositório é que o que quer que esteja por trás dele não importa, desde que a API que ele fornece funcione para a camada do aplicativo que a chama.
E já que cobrimos uma cartilha sobre o padrão de repositório, vamos dar uma olhada em alguns dos benefícios do padrão de repositório e como podemos implementá-lo no contexto de projetos do WordPress.
Benefícios do padrão de repositório
Existem algumas maneiras de começar a explicar o padrão, então vou começar com um diagrama simples:
Os benefícios do padrão de repositório incluem abstração de armazenamento de dados
Observe na imagem acima, existem três componentes principais:
- a lógica de domínio (ou a lógica de negócios) que rotulei como "Aplicativo",
- o repositório,
- o armazenamento de dados,
Em relação à aplicação, as regras de negócio permanecerão sempre relativamente consistentes. Pelo menos deveriam, certo?
O repositório é o que atua como um meio de comunicação entre a lógica de negócios e o armazenamento de dados.
Agora, o armazenamento de dados pode ser um banco de dados, talvez um conjunto de arquivos (o que eu não recomendaria), uma API para terceiros, uma lista de informações recuperadas de outro aplicativo e assim por diante.
O ponto é que o repositório fornecerá uma API limpa na qual a lógica de negócios pode gravar e ler (e mais sobre isso daqui a pouco) sem se preocupar com os detalhes de para onde os dados estão indo ou como estão voltando.
Esse é o trabalho do repositório. E é isso que torna importante ter uma API consistente e é isso que é importante para garantir que ela tenha os detalhes de implementação do armazenamento de dados com o qual está interagindo.
No acoplamento
Além de ter seu aplicativo devidamente segmentado, o padrão de repositório beneficia a arquitetura, pois ajuda a desacoplar as partes do seu aplicativo.
Ou seja, a lógica de negócios não sabe nada sobre como ou onde os dados são armazenados. Ele apenas sabe que pode escrevê-lo e recuperá-lo e pode fazê-lo usando uma API limpa.
O repositório é responsável por comunicar o referido armazenamento de dados para orquestrar a serialização e a recuperação, mas deve fornecer uma API consistente, para que a camada de dados não precise fazer nenhuma ginástica de sintaxe para ler e gravar suas informações.
Detalhes de implementação
Até este ponto, tenho representado o repositório como uma classe concreta.
O problema é que um aplicativo provavelmente terá vários repositórios. E por causa disso, é uma boa ideia ter interfaces que cada repositório possa implementar.
É assim que você define o contrato de métodos que o repositório fornecerá. E é assim que você pode garantir que cada repositório esteja conectado ao armazenamento de dados adequado.
Uma implementação de interface para vários repositórios.
Então, digamos que seu aplicativo precise conversar com o banco de dados do WordPress, bem como com uma API de terceiros.
Idealmente, a interface forneceria um conjunto comum de métodos, mas os detalhes de implementação variariam por repositório, pois cada repositório terá as credenciais necessárias e a capacidade de se comunicar com o armazenamento de dados.
O avanço para a interface, porém, é o que dá ao padrão seu poder. A lógica de domínio não precisa se preocupar com como as informações são salvas ou recuperadas. Ele simplesmente chama os métodos conforme definidos na interface e o objeto necessário cuida disso.
Ele simplesmente chama os métodos conforme definidos na interface e o objeto necessário cuida disso.
Como seria isso no WordPress?
Esta é uma boa pergunta (e não, eu não inventei apenas para responder por conta própria 🙂), e pode ser difícil dar um ótimo exemplo porque muito do que fazemos interage diretamente com o banco de dados do WordPress.
Isso não significa que não haja abstrações que possamos usar, como Posts, Páginas, Usuários ou qualquer outro tipo de postagem personalizado que optamos por criar.
Mas o WordPress fornece uma API para muito disso. Eu posso ver um caso em que, digamos, um usuário com campos adicionais que foram adicionados poderia se beneficiar de um Repositório de Usuários.
Ou um tipo de postagem personalizado com muitos metadados também pode se beneficiar de um repositório ao ter os detalhes encapsulados no repositório.
Um exemplo de alto nível
Digamos, por exemplo, que você tenha um tipo de postagem personalizado para um evento, e o evento tenha um título e uma descrição que se encaixem naturalmente no título e no conteúdo da postagem.
Mas então ele tem metadados sobre sua localização, seu horário de início, seu horário de término e assim por diante. Isso também pode ser encapsulado pelo repositório para que você possa ter um objeto Event, passá-lo para o repositório e permitir que o repositório envie as informações para o local apropriado no banco de dados.
E o mesmo vale para recuperar as informações: ele sabe onde obtê-las, como preencher um objeto Event e, em seguida, devolvê-las ao chamador.
De volta à pista
Mas toda essa conversa sobre um evento está ficando um pouco fora do tópico, então talvez eu continue falando sobre isso e como ele se encaixa com o repositório em um post de acompanhamento. Claramente, ao falar sobre isso, há muito o que cobrir.
Eu prefiro levá-lo em passos menores
Resumindo, se você tiver um Repositório de Eventos, provavelmente terá um objeto Evento ou uma entidade Evento. E como isso se encaixa no WordPress, tipos de postagem personalizados, metadados e assim por diante introduz um nível de complexidade que pode parecer assustador no início, mas compensa quando se trabalha com um aplicativo da Web maior.