Um exemplo geral do padrão de repositório no WordPress

Na minha experiência, a maneira como interagimos pela primeira vez com o padrão de design do repositório geralmente influencia como pensamos sobre o padrão. (Todas as primeiras impressões são impressões duradouras, certo?)

O objetivo deste post é mostrar como ele pode ser implementado no WordPress especificamente ao escrever plugins orientados a objetos para ler dados (escrever dados pode ser abordado em outro post), mas antes de fazer isso tentei pensar em algumas consistências entre os variações do padrão que eu vi.

De um modo geral, isso é o que eu acho que um padrão de repositório deve fazer:

• fornecer um único local para ler dados,
• abstrair os detalhes de como os dados são acessados,
• e ter uma interface consistente para isso.

Isso significa que tudo o que você precisa recuperar do aplicativo pode ser recuperado do banco de dados. Mas como é recuperado pode ser considerado uma caixa preta. Isso depende do desenvolvedor que implementa o padrão.

E no caso para quem lê este post, provavelmente somos nós.

O padrão de repositório no WordPress

Alguns anos atrás, escrevi sobre o padrão de repositório dando um exemplo concreto. Ainda é relevante, mas o propósito do que quero abordar neste post é um pouco diferente.

Em vez de mostrar uma implementação específica baseada em um exemplo real, prefiro defender como podemos empregar esse padrão em nosso trabalho diário.

As duas coisas a ter em mente ao ler isso são:

1. da perspectiva do usuário, o armazenamento de dados subjacente não importa,
2. da perspectiva do desenvolvedor, o padrão nos permite trabalhar com várias fontes de dados e também simular um armazenamento de dados de amostra para que possamos testar os dados em unidade.

Ao implementar o padrão, não importa de onde os dados vêm. Pelo menos enquanto você for o objeto de desenvolvedor ou cliente que o chama. O armazenamento de dados pode ser um banco de dados, um conjunto de funções de API ou uma combinação de ambos.

Vamos supor, então, que você está trabalhando com um tipo de postagem personalizado para Eventos e também está trabalhando com metadados de postagem e opções relacionadas a algo como eventos.

Você pode fazer algo como:

• obter o nome do evento,
• encontrar informações sobre o local do evento,
• recuperar o primeiro tipo de postagem e status ordenado por seu ID

Todas essas informações podem estar espalhadas em diferentes lugares e a forma como são recuperadas pode variar.

1 Obtendo o Nome do Evento

Se estivermos trabalhando com um tipo de postagem personalizado e precisarmos obter o nome do evento, podemos usar o ID de uma postagem e uma das funções da API do WordPress para fazer isso.

<?php

/**
 * Retrieves the title of the Event, a custom post type.
 *
 * @param  int    $eventId the ID of the event post type
 * @return string          the title of the post.
 */
public function getName(int $eventId): string
{
  return get_the_title($eventId);
}

Este é um caso em que o armazenamento de dados ainda é abstraído de nós e, em vez disso, aproveita a API existente do WordPress.

2 Obtendo o local do evento

Nesse caso, podemos supor que o local do evento foi inserido manualmente ou talvez recuperado por uma API de terceiros. E como o local está associado a um evento específico, ele pode estar na tabela de metadados de postagem.

Novamente, podemos recuperá-lo usando funções de API pré-existentes; no entanto, em situações como essa, faz sentido ter uma função auxiliar porque provavelmente também acessaremos outros metadados.

Então, primeiro, o ajudante :

<?php 
/**
 * A helper function for easily retrieving post meta data for a given Event.
 *
 * @param int    $id  the ID of the event
 * @param string $key the key for the post meta data for which we're retrieveing the data
 *
 * @return string the result of retrieiving the meta data
 */
private function get(int $id, string $key): string
{
    return get_post_meta($id, $key, true);
}

E então a função que usa o auxiliar para obter a localização :

<?php
/**
 * @param  int    $eventID the ID of the event
 * @return string          the name of the event of an empty string
 */
public function getLocationName($eventId): string
{
    return $this->get($eventId, 'ymc-event-location-name');
}

Mas nestes dois exemplos, ainda estamos usando funções de API existentes. E o caso em que precisamos falar com o banco de dados?

3 Recuperando um único URL de postagem

Nesse caso, estaremos nos comunicando diretamente com o banco de dados do WordPress. Se você estiver familiarizado com o objeto $wpdb e SQL, isso não será um grande problema.

Se não estiver, recomendo ler sobre a função prepare, bem como a função get_results.

Dado isso, podemos escrever uma consulta que fará o seguinte:

1. pegue todas as postagens em que o ID corresponde a um determinado valor, o tipo de postagem e o status da postagem são um determinado valor, e ordenaremos os resultados por valor crescente do ID,
2. em seguida, usaremos os resultados dessa consulta para obter um único valor.

E podemos fazer isso acessando o banco de dados e escrevendo uma consulta aninhada:

<?php

/**
 * @return string the URL to the event next to the current event.
 */
public function getNextEventUrl()
{
    global $wpdb;
    $results = $wpdb->get_results(
        $wpdb->prepare(
            "
            SELECT *
            FROM $wpdb->posts
            WHERE ID > (SELECT ID
                FROM $wpdb->posts
                WHERE ID = %d
                AND post_type = '%s'
                AND post_status = '%s'
                ORDER BY ID ASC) AND post_type = '%s'
            AND post_status = '%s'
            ORDER BY ID ASC
            LIMIT 1
        ",
            get_the_ID(),
            'ymc-events',
            'publish',
            'ymc-events',
            'publish') );

  $result = (isset($result[0]))? $result[0]: '';

  return $result;
}

E então tudo isso pode ser encapsulado em uma única classe que seria, digamos, o Event Repository (ou EventRepository ).

Eu vou ter mais sobre isso em um post de acompanhamento, no entanto. Ou seja, como lidar com determinar quais funções pertencem a onde, as convenções de nomenclatura e como lidar com a persistência, caso você queira introduzir isso em seu repositório também.

Repositório definido

Acima de tudo, tenha isso em mente:

O padrão de repositório mascara como os dados são recuperados, mas fornece uma maneira consistente de como os dados com os quais estão relacionados podem ser recuperados.

Alguns também podem adicionar como ele pode ser recuperado e como pode ser escrito, mas talvez eu discuta isso em outro post.