Ett allmänt exempel på förvarsmönstret i WordPress

Enligt min erfarenhet påverkar sättet vi först interagerar med förvarsdesignmönstret ofta hur vi tänker om mönstret. (Hela första intrycken är bestående intryck, eller hur?)

Syftet med det här inlägget är att visa hur det kan implementeras i WordPress specifikt när man skriver objektorienterade plugins för att läsa data (skrivdata kan täckas i ett annat inlägg), men innan jag gjorde det försökte jag tänka på några konsistenser bland de varianter av mönstret som jag har sett.

Generellt sett är detta vad jag tycker att ett förvarsmönster bör göra:

• tillhandahålla en enda plats att läsa data,
• abstrahera detaljerna om hur data nås,
• och har ett konsekvent gränssnitt för att göra det.

Det betyder att vad du än behöver hämta från applikationen kan hämtas från databasen. Men hur det hämtas kan betraktas som en svart låda. Det är upp till utvecklaren som implementerar mönstret.

Och i fallet för dem som läser det här inlägget så är det med största sannolikhet vi.

Förvarsmönstret i WordPress

För ett par år sedan skrev jag om förvarsmönstret och gav ett konkret exempel. Det är fortfarande relevant, men syftet med det jag vill ta upp i det här inlägget är lite annorlunda.

Istället för att visa en viss implementering med rötter i ett verkligt exempel vill jag hellre argumentera för hur vi kan använda detta mönster i vårt dagliga arbete.

De två sakerna att tänka på när du läser detta är:

1. ur användarens perspektiv spelar den underliggande datalagringen ingen roll,
2. ur utvecklarens perspektiv tillåter mönstret oss att arbeta med flera datakällor och även håna ett exempeldatalager så att vi kan enhetstesta data.

När du implementerar mönstret spelar det ingen roll var data kommer ifrån. Åtminstone så länge som du är utvecklaren eller klientobjektet som anropar det. Datalagret kan vara en databas, en uppsättning API-funktioner eller en kombination av båda.

Anta då att du arbetar med en anpassad inläggstyp för Events och att du också arbetar med inläggsmetadata och alternativ relaterade till något som händelser.

Du kan göra något som:

• få namnet på händelsen,
• hitta information om platsen för evenemanget,
• hämta den första posttypen och statusen sorterad efter dess ID

All denna information kan vara spridd på olika platser och hur den hämtas kan variera.

1 Hämta händelsenamnet

Om vi ​​arbetar med en anpassad inläggstyp och vi behöver få händelsenamnet kan vi använda ett inläggs ID och en av WordPress API-funktioner för att göra det.

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

Detta är ett fall där datalagret fortfarande är abstraherat från oss och istället utnyttjar det befintliga WordPress API.

2 Hämta händelseplatsen

I det här fallet kan vi anta att händelseplatsen har angetts manuellt eller kanske har hämtats av ett tredje parts API. Och eftersom platsen är associerad med en specifik händelse kan den finnas i postmetadatatabellen.

Återigen, vi kan hämta det med hjälp av redan existerande API-funktioner; Men i sådana här situationer är det vettigt att ha en hjälpfunktion eftersom vi sannolikt också kommer åt annan metadata.

Så först, hjälparen :

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

Och sedan funktionen som använder hjälparen för att få platsen :

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

Men i dessa två exempel använder vi fortfarande befintliga API-funktioner. Hur är det med fallet där vi behöver prata med databasen?

3 Hämta en URL för ett inlägg

I det här fallet kommer vi att kommunicera direkt med WordPress-databasen. Om du är bekant med $wpdb- objektet och SQL kommer detta inte att vara en stor sak.

Om du inte är det rekommenderar jag att du läser om funktionen förbereda såväl som funktionen get_results.

Med tanke på detta kan vi skriva en fråga som gör följande:

1. ta tag i alla inlägg där ID matchar ett visst värde, inläggstyp och inläggsstatus är ett visst värde, så ordnar vi resultaten efter stigande värde på ID,
2. sedan använder vi resultaten av den frågan för att få ett enda värde.

Och vi kan göra detta genom att både komma åt databasen och skriva en kapslad fråga:

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

Och sedan kan allt detta inkapslas i en enda klass som skulle vara, säg, Event Repository (eller EventRepository ).

Jag kommer dock att ha mer om detta i ett uppföljande inlägg. Nämligen, hur man hanterar bestämmer vilka funktioner som hör hemma var, namnkonventionerna och hur man hanterar persistens om du också vill introducera det i ditt arkiv.

Lagringsplats definierad

Ha framför allt detta i åtanke:

Förvarsmönstret maskerar hur data hämtas men ger ett konsekvent sätt för hur data som den är relaterad till kan hämtas.

Vissa kanske också lägger till hur det kan hämtas och hur det kan skrivas, men det kanske jag tar upp i ett annat inlägg.