Un esempio generale del modello di repository in WordPress

Nella mia esperienza, il modo in cui interagiamo per la prima volta con il pattern di progettazione del repository spesso influenza il modo in cui pensiamo al pattern. (Tutte le prime impressioni sono impressioni durature, giusto?)

Lo scopo di questo post è mostrare come può essere implementato in WordPress nello specifico quando si scrivono plugin orientati agli oggetti per leggere i dati (la scrittura dei dati potrebbe essere trattata in un altro post), ma prima di farlo ho cercato di pensare ad alcune coerenze tra i variazioni del modello che ho visto.

In generale, questo è ciò che penso dovrebbe fare un modello di repository:

• fornire un unico posto per leggere i dati,
• astrarre i dettagli di come si accede ai dati,
• e avere un’interfaccia coerente per farlo.

Ciò significa che tutto ciò che è necessario recuperare dall’applicazione può essere recuperato dal database. Ma come è stato recuperato può essere considerato una scatola nera. Dipende dallo sviluppatore che implementa il modello.

E nel caso per coloro che leggono questo post, molto probabilmente siamo noi.

Il modello di repository in WordPress

Un paio di anni fa, ho scritto del pattern del repository fornendo un esempio concreto. È ancora rilevante, ma lo scopo di ciò che voglio trattare in questo post è un po’ diverso.

Piuttosto che mostrare un’implementazione particolare radicata in un esempio reale, preferirei illustrare come possiamo utilizzare questo modello nel nostro lavoro quotidiano.

Le due cose da tenere a mente durante la lettura sono:

1. dal punto di vista dell’utente, il datastore sottostante non ha importanza,
2. dal punto di vista dello sviluppatore, il modello ci consente di lavorare con più origini dati e anche di simulare un archivio dati di esempio in modo da poter testare i dati in unità.

Quando si implementa il modello, da dove provengono i dati non ha importanza. Almeno finché sei l’oggetto sviluppatore o client che lo chiama. L’archivio dati può essere un database, un insieme di funzioni API o una combinazione di entrambi.

Supponiamo, quindi, che stai lavorando con un tipo di post personalizzato per Eventi e stai anche lavorando con i metadati dei post e le opzioni relative a qualcosa come gli eventi.

Potresti fare qualcosa come:

• ottenere il nome dell’evento,
• trovare informazioni sulla location dell’evento,
• recuperare il primo tipo di post e lo stato ordinato in base al suo ID

Tutte queste informazioni possono essere sparse in luoghi diversi e il modo in cui vengono recuperate può variare.

1 Ottenere il nome dell’evento

Se stiamo lavorando con un tipo di post personalizzato e abbiamo bisogno di ottenere il nome dell’evento, allora possiamo usare l’ID di un post e una delle funzioni API di WordPress per farlo.

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

Questo è un caso in cui l’archivio dati è ancora sottratto a noi e, invece, sfrutta l’API di WordPress esistente.

2 Ottenere la posizione dell’evento

In questo caso, possiamo presumere che il luogo dell’evento sia stato inserito manualmente o forse sia stato recuperato da un’API di terze parti. E poiché la posizione è associata a un evento specifico, potrebbe trovarsi nella tabella dei metadati del post.

Ancora una volta, possiamo recuperarlo utilizzando funzioni API preesistenti; tuttavia, in situazioni come questa, ha senso avere una funzione di supporto perché probabilmente accederemo anche ad altri metadati.

Quindi, per prima cosa, l’aiutante :

<?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 poi la funzione che usa l’helper per ottenere la posizione :

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

Ma in questi due esempi, stiamo ancora utilizzando le funzioni API esistenti. E il caso in cui dobbiamo parlare con il database?

3 Recupero di un URL di un singolo post

In questo caso, comunicheremo direttamente con il database di WordPress. Se hai familiarità con l’ oggetto $wpdb e SQL, questo non sarà un grosso problema.

In caso contrario, ti consiglio di leggere la funzione prepare e la funzione get_results.

Detto questo, possiamo scrivere una query che farà quanto segue:

1. prendi tutti i post in cui l’ID corrisponde a un certo valore, il tipo e lo stato del post hanno un certo valore e ordineremo i risultati in base al valore crescente dell’ID,
2. successivamente, utilizzeremo i risultati di quella query per ottenere un singolo valore.

E possiamo farlo sia accedendo al database che scrivendo una query nidificata:

<?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 poi tutto questo può essere incapsulato in una singola classe che sarebbe, diciamo, Event Repository (o EventRepository ).

Ne parlerò di più in un post di follow-up, però. Vale a dire, come gestire determina quali funzioni appartengono a dove, le convenzioni di denominazione e come gestire la persistenza se vuoi introdurla anche nel tuo repository.

Repository definito

Soprattutto, tieni presente questo:

Il modello di repository maschera il modo in cui i dati vengono recuperati, ma fornisce un modo coerente per il modo in cui è possibile recuperare i dati con cui è correlato.

Alcuni potrebbero anche aggiungere come può essere recuperato e come può essere scritto, ma forse ne parlerò in un altro post.