Un ejemplo general del patrón de repositorio en WordPress

En mi experiencia, la forma en que primero interactuamos con el patrón de diseño del repositorio a menudo influye en cómo pensamos sobre el patrón. (Todas las primeras impresiones son impresiones duraderas, ¿verdad?)

El propósito de esta publicación es mostrar cómo se puede implementar en WordPress específicamente cuando se escriben complementos orientados a objetos para leer datos (la escritura de datos puede tratarse en otra publicación), pero antes de hacerlo, traté de pensar en algunas consistencias entre los variaciones del patrón que he visto.

En términos generales, esto es lo que creo que debería hacer un patrón de repositorio:

• proporcionar un solo lugar para leer datos,
• abstraer los detalles de cómo se accede a los datos,
• y tener una interfaz consistente para hacerlo.

Esto significa que cualquier cosa que necesite recuperar de la aplicación puede recuperarse de la base de datos. Pero cómo se recupera puede considerarse una caja negra. Eso depende del desarrollador que implemente el patrón.

Y en el caso de aquellos que leen esta publicación, lo más probable es que seamos nosotros.

El patrón de repositorio en WordPress

Hace un par de años, escribí sobre el patrón de repositorio dando un ejemplo concreto. Todavía es relevante, pero el propósito de lo que quiero cubrir en esta publicación es un poco diferente.

En lugar de mostrar una implementación particular arraigada en un ejemplo real, prefiero exponer cómo podemos emplear este patrón en nuestro trabajo diario.

Las dos cosas a tener en cuenta al leer esto son:

1. desde la perspectiva del usuario, el almacén de datos subyacente no importa,
2. desde la perspectiva del desarrollador, el patrón nos permite trabajar con múltiples fuentes de datos y también simular un almacén de datos de muestra para que podamos realizar pruebas unitarias de los datos.

Al implementar el patrón, no importa de dónde provengan los datos. Al menos mientras sea el desarrollador o el objeto del cliente que lo llama. El almacén de datos puede ser una base de datos, un conjunto de funciones API o una combinación de ambos.

Supongamos, entonces, que está trabajando con un tipo de publicación personalizada para Eventos y también está trabajando con metadatos de publicación y opciones relacionadas con algo como eventos.

Puede hacer algo como:

• obtener el nombre del evento,
• encontrar información sobre la ubicación del evento,
• recuperar el primer tipo de publicación y el estado ordenado por su ID

Toda esta información puede estar dispersa en diferentes lugares y la forma en que se recupera puede variar.

1 Obtener el nombre del evento

Si estamos trabajando con un tipo de publicación personalizada y necesitamos obtener el nombre del evento, entonces podemos usar la ID de una publicación y una de las funciones API de WordPress para hacerlo.

<?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 es un caso en el que el almacén de datos aún se abstrae de nosotros y, en su lugar, aprovecha la API de WordPress existente.

2 Obtener la ubicación del evento

En este caso, podemos suponer que la ubicación del evento se ingresó manualmente o tal vez fue recuperada por una API de terceros. Y dado que la ubicación está asociada con un evento específico, entonces puede estar en la tabla de metadatos de la publicación.

Nuevamente, podemos recuperarlo usando funciones API preexistentes; sin embargo, en situaciones como esta, tiene sentido tener una función auxiliar porque probablemente también accederemos a otros metadatos.

Así que primero, el ayudante :

<?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);
}

Y luego la función que usa el ayudante para obtener la ubicación :

<?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');
}

Pero en estos dos ejemplos, todavía estamos usando funciones API existentes. ¿Qué pasa con el caso en que necesitamos hablar con la base de datos?

3 Recuperar una URL de publicación única

En este caso, nos comunicaremos directamente con la base de datos de WordPress. Si está familiarizado con el objeto $wpdb y SQL, esto no será gran cosa.

Si no es así, le recomiendo leer sobre la función de preparación y la función get_results.

Dado esto, podemos escribir una consulta que hará lo siguiente:

1. tome todas las publicaciones donde la ID coincida con un cierto valor, el tipo de publicación y el estado de la publicación tienen un valor determinado, y ordenaremos los resultados por valor ascendente de la ID,
2. a continuación, usaremos los resultados de esa consulta para obtener un valor único.

Y podemos hacer esto accediendo a la base de datos y escribiendo una consulta anidada:

<?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;
}

Y luego todo esto se puede encapsular en una sola clase que sería, por ejemplo, el Repositorio de eventos (o EventRepository ).

Sin embargo, tendré más sobre esto en una publicación de seguimiento. Es decir, cómo manejar determinar qué funciones pertenecen a dónde, las convenciones de nomenclatura y cómo manejar la persistencia si también desea introducir eso en su repositorio.

Repositorio definido

Por encima de todo, ten esto en cuenta:

El patrón de repositorio enmascara cómo se recuperan los datos, pero proporciona una forma coherente de cómo se pueden recuperar los datos con los que está relacionado.

Algunos también pueden agregar cómo se puede recuperar y cómo se puede escribir, pero tal vez lo discuta en otra publicación.