WordPressi hoidla mustri üldine näide

Minu kogemuse kohaselt mõjutab see, kuidas me esimest korda hoidla kujundusmustriga suhtleme, sageli seda, kuidas me mustrist mõtleme. (Kogu esmamuljed on püsivad, eks?)

Selle postituse eesmärk on näidata, kuidas seda saab WordPressis rakendada just siis, kui kirjutate andmete lugemiseks objektorienteeritud pistikprogramme (andmete kirjutamist võib käsitleda mõnes teises postituses), kuid enne seda proovisin välja mõelda mõned järjepidevused mustri variatsioonid, mida olen näinud.

Üldiselt arvan, et hoidla muster peaks seda tegema:

• pakkuda ühte kohta andmete lugemiseks,
• tehke kokkuvõte üksikasjadest, kuidas andmetele juurde pääseb,
• ja neil on selleks ühtne liides.

See tähendab, et kõik, mida peate rakendusest alla laadima, saab hankida andmebaasist. Kuid seda, kuidas see välja otsiti, võib pidada mustaks kastiks. See on mustri rakendava arendaja ülesanne.

Ja nende jaoks, kes seda postitust loevad, oleme tõenäoliselt meie.

WordPressi hoidla muster

Paar aastat tagasi kirjutasin hoidla mustrist, tuues konkreetse näite. See on endiselt asjakohane, kuid selle postituse eesmärk on pisut erinev.

Selle asemel, et näidata konkreetset teostust, mis põhineb tegelikul näitel, tahaksin pigem selgitada, kuidas saaksime seda mustrit oma igapäevases töös kasutada.

Seda lugedes tuleb meeles pidada kahte asja:

1. kasutaja seisukohast pole aluseks olev andmesalv oluline,
2. arendaja vaatevinklist võimaldab muster meil töötada mitme andmeallikaga ja teha ka näidisandmesalve, et saaksime andmeid katsetada.

Mustri rakendamisel pole andmete päritolul tähtsust. Vähemalt seni, kuni olete arendaja või kliendiobjekt, kes sellesse helistab. Andmesalv võib olla andmebaas, API funktsioonide komplekt või mõlema kombinatsioon.

Oletame siis, et töötate sündmuste jaoks kohandatud postitustüübiga ning töötate ka postituste metaandmete ja sündmustega seotud valikutega.

Võite teha midagi sellist:

• hankige sündmuse nimi,
• leida infot ürituse asukoha kohta,
• hankida esimene postituse tüüp ja olek, mis on järjestatud selle ID järgi

Kogu see teave võib olla erinevatesse kohtadesse laiali ja selle hankimise viis võib olla erinev.

1 Sündmuse nime hankimine

Kui töötame kohandatud postituse tüübiga ja peame saama sündmuse nime, saame selleks kasutada postituse ID-d ja üht WordPressi API funktsiooni.

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

See on üks juhtum, kus andmesalv on ikka veel meist eemal ja selle asemel kasutab olemasolevat WordPressi API-d.

2 Sündmuse asukoha hankimine

Sel juhul võime eeldada, et sündmuse asukoht on käsitsi sisestatud või võib-olla on selle alla laaditud kolmanda osapoole API. Ja kuna asukoht on seotud konkreetse sündmusega, võib see olla postituse metaandmete tabelis.

Jällegi saame selle hankida juba olemasolevate API funktsioonide abil; aga sellistes olukordades on mõttekas kasutada abifunktsiooni, sest tõenäoliselt pääseme juurde ka teistele metaandmetele.

Nii et kõigepealt abimees :

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

Ja siis funktsioon, mis kasutab asukoha leidmiseks abistajat :

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

Kuid nendes kahes näites kasutame endiselt olemasolevaid API funktsioone. Kuidas on lood siis, kui peame andmebaasiga rääkima?

3 Ühe postituse URL-i toomine

Sel juhul suhtleme otse WordPressi andmebaasiga. Kui olete $ wpdb objekti ja SQL-iga tuttav, pole see suur asi.

Kui te seda ei tee, soovitan lugeda nii ettevalmistamisfunktsiooni kui ka funktsiooni get_results kohta.

Seda arvestades saame kirjutada päringu, mis teeb järgmist:

1. haarake kõik postitused, mille ID vastab kindlale väärtusele, postituse tüüp ja postituse olek on kindlad väärtused, ning järjestame tulemused ID kasvavas väärtuses,
2. järgmiseks kasutame selle päringu tulemusi ühe väärtuse saamiseks.

Ja seda saame teha nii andmebaasi juurde pääsedes kui ka pesastatud päringu kirjutades:

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

Ja siis saab selle kõik kapseldada ühte klassi, mis oleks näiteks sündmuste hoidla (või EventRepository ).

Sellest aga räägin pikemalt ühes järgnevas postituses. Nimelt, kuidas käsitleda funktsioonide, kuhu kuuluvad, määramist, nimetamiskokkuleppeid ja püsivust, kui soovite seda ka oma hoidlasse tutvustada.

Hoidla on määratletud

Eelkõige pidage meeles järgmist:

Hoidla muster varjab andmete toomise viisi, kuid annab järjepideva viisi sellega seotud andmete hankimiseks.

Mõni võib ka lisada, kuidas seda saab kätte saada ja kuidas seda kirjutada, aga võib-olla räägin sellest mõnes teises postituses.