O primer do padrão de repositório

Sempre que você estiver trabalhando em um projeto maior baseado no WordPress, as chances de trabalhar com mais de uma única fonte de dados – ou seja, o banco de dados do WordPress – são maiores que o normal. Por exemplo, você pode estar trabalhando em um projeto que precisa coordenar informações de:

• o banco de dados do WordPress,
• um sistema de tíquetes de help desk,
• um sistema de importação de conteúdo,
• outra API de terceiros,
• e possível mais.

E quando isso acontece, pode se tornar um pouco complicado escrever código que facilite a recuperação de informações desses lugares diferentes. É disso que os desenvolvedores costumam falar quando se referem a lidar com “camadas" em seus aplicativos.

• existem camadas para apresentar informações ao usuário,
  camadas para lidar com a lógica de negócios (ou lógica de domínio),
• camadas para comunicação com APIs,
• e camadas para armazenamento de dados.

Honestamente, você não precisa ter uma variedade de armazenamentos de dados para observar para criar uma camada que facilite o envio e a recuperação de dados do banco de dados, é exatamente quando isso é mais comum. Você pode trabalhar com a mesma eficácia com um único armazenamento de dados, como o banco de dados WordPress, ao implementar o padrão de repositório.

Independentemente disso, se você estiver construindo um site maior, aplicativo da Web ou plug-in, implementar o padrão de repositório é algo que pode render dividendos em manutenção, clareza de código e separação de interesses.

Mas como isso pode ser implementado no WordPress? Não é muito desafiador, mas primeiro, vale a pena revisar uma cartilha de repositório antes de pular para qualquer código.

Um primer de padrão de repositório

Antes de olhar para uma implementação real no WordPress, é importante entender o que é o repositório, como ele é definido, o que ele oferece e uma implementação genérica dele. Compartilharei algumas leituras adicionais no final do artigo, mas até lá cobrirei minha opinião geral sobre o padrão aqui.

Primeiro, uma implementação desse padrão pode se tornar mais complicada do que o necessário para iniciantes. Isso não quer dizer que o padrão real não valha a pena entender, mas se você está apenas querendo se molhar com isso, não sou fã de jogar os leitores no fundo do poço. Não acho que seja a melhor maneira de aprender.

Em vez disso, vale a pena quebrar o problema e depois reconstruí-lo em algo um pouco mais elegante. Então é isso que eu pretendo fazer.

Uma palavra sobre desacoplamento

Ao falar sobre programação orientada a objetos, muitas vezes falamos sobre a ideia de “desacoplar” partes do sistema. Se você está familiarizado com acoplamento e coesão, então sabe por quê.

Mas se não, basta dizer que quanto mais acoplados forem os componentes do seu sistema, mais difícil será alterá-los. Eles sabem muito um do outro. Ou seja, se você alterar um dos aspectos do sistema, é provável que ocorra uma cascata ou impacto em outra parte do sistema que você nunca quis que acontecesse. Então você tem que gastar muito mais tempo corrigindo todos esses outros “pontos de contato” em todo o sistema que não deveriam ser necessários.

A implementação de várias estratégias, como o padrão de repositório, pode ajudar a desacoplar partes do sistema. Caso em questão: a camada de apresentação não sabe como o armazenamento de dados subjacente é a organização. Ele não precisa saber SQL. Ele não precisa saber que é um banco de dados. Em vez disso, ele só precisa saber como falar com o repositório.

Legal, certo?

Isso significa que você pode trocar o armazenamento de dados de back-end e, supondo que sua API seja sólida; seu aplicativo continuará funcionando com pouca ou nenhuma alteração. E é isso que significa ser verdadeiramente dissociado.

Uma implementação do padrão de repositório

Então, como é o padrão do repositório? Como acontece com a maioria dos padrões de design, há uma forma genérica do padrão, e isso é sempre útil, mas acho que também ajuda aqueles que trabalham no WordPress a ver como ele pode funcionar no contexto do WordPress. 

Então, primeiro, quero detalhar o padrão em si e, em seguida, dar um exemplo de como pode ser ao trabalhar com o WordPress.

Um Implemento Genérico do Padrão de Repositório

A implementação real do padrão de repositório é bem simples. Na verdade, nunca tenho certeza se isso é útil porque apenas mostra como os armazenamentos de dados, o repositório e o restante do aplicativo interagem entre si.

Não me entenda mal: sou a favor de modelos conceituais de como as coisas são organizadas. Pessoalmente, isso me ajuda a pensar na estrutura de um aplicativo ao construí-lo, mas se for muito geral, não ajudará muito.

Mas para chegar a um implemento concreto, temos que começar de algum lugar, certo? Então eu vou começar no nível mais alto possível e trabalhar para baixo.

Como você pode ver na imagem acima, você tem alguns armazenamentos de dados que são lidos por meio do repositório e, em seguida, o aplicativo consulta o repositório que, por sua vez, recupera informações do armazenamento de dados.

Sim, existem opções para armazenar informações em cache, invalidar o cache e todas essas coisas divertidas. Mas está fora do escopo de um primário do repositório. Portanto, não vou seguir esse caminho específico por enquanto. Talvez em um post futuro (se este for útil para você).

O padrão de repositório no WordPress

Então, com isso dito, vamos dar uma olhada em uma implementação básica de como isso pode parecer em uma instalação padrão do WordPress. Ou seja, tudo o que temos é o armazenamento de dados. Não estamos nos comunicando com mais nada, mas queremos garantir que qualquer coisa que faça interface com o banco de dados ou a API seja tratada pelo repositório

Isso ficaria mais ou menos assim:

Como pode ficar com o WordPress

E isso pode ser abstraído ainda mais. Talvez haja um Post Repository ou um User Repository. Pessoalmente, sou fã de ter um repositório para cada tipo de entidade porque ajuda a conter a lógica de negócios relacionada sem criar aquelas grandes classes que sabem tudo (e desnecessariamente).

Então isso pode ficar assim:

Um pacote de repositórios

Então vamos subir mais um nível e dizer que você está trabalhando com a API do Twitter, a API do ZenDesk, a API do usuário do WordPress e a API do WordPress Post. Então o que? Existem mais repositórios.

Talvez eles estejam contidos em seu namespace (o que deveriam estar), talvez estejam implementando uma interface comum (para o qual há um caso para isso), mas durante o tempo de desenvolvimento, acho importante declarar explicitamente qual repositório você está usando para ser o mais claro possível.

Ou seja, não use um genérico e deixe o tempo de execução descobrir:

$support_repository = new Support_Repository();
$support_repository->get_tickets_for( 'tommcfarlin' );

Em vez disso, seja explícito:

$zendesk_repository = new ZenDesk_Repository();
$zendesk_repository->get_tickets_from( 'yesterday' );

Isso pode parecer muito. Não sei se você experimenta isso, mas há uma sensação estranha na programação orientada a objetos, onde queremos criar as classes pequenas e focadas, mas isso cria muitos arquivos.

Então você tem esses arquivos bem configurados, cada um dos quais está fazendo algo pequeno e proposital. Não deixe que a quantidade de arquivos que compõem um projeto dê a impressão de que você tem uma arquitetura ruim.

Conclusão

Esta é a cartilha do padrão de repositório. Naturalmente, há código que acompanha isso, mas antes de mergulhar nessa parte – porque código é onde as coisas se perdem facilmente na tradução – eu queria ter certeza de ajudar a fornecer uma ilustração para desenvolver um modelo conceitual de como o padrão funciona.

A partir daqui, podemos começar a falar sobre uma implementação do padrão. Então, no próximo post ou nos próximos posts, vou fazer exatamente isso.

Enquanto isso, não hesite em deixar comentários ou perguntas sobre o que abordamos aqui.

Leitura Relacionada

• O Padrão do Repositório via 8ª Luz
• O padrão de repositório via MSDN
• Uma implementação do padrão de repositório