Z mojego doświadczenia wynika, że sposób, w jaki po raz pierwszy wchodzimy w interakcję ze wzorcem projektu repozytorium, często wpływa na to, jak myślimy o wzorcu. (Całe pierwsze wrażenia są trwałymi wrażeniami, prawda?)
Celem tego postu jest pokazanie, jak można go zaimplementować w WordPressie, szczególnie podczas pisania wtyczek obiektowych do odczytu danych (zapisywanie danych może być omówione w innym poście), ale zanim to zrobiłem, próbowałem wymyślić kilka spójności między wariacje wzoru, który widziałem.
Ogólnie rzecz biorąc, uważam, że wzorzec repozytorium powinien robić:
- zapewnić jedno miejsce do odczytu danych,
- streszczenie szczegółów sposobu dostępu do danych,
- i mieć do tego spójny interfejs.
Oznacza to, że wszystko, co trzeba pobrać z aplikacji, można pobrać z bazy danych. Ale sposób jego odzyskania można uznać za czarną skrzynkę. To zależy od programisty implementującego wzorzec.
A w przypadku tych, którzy czytają ten post, to najprawdopodobniej my.
Wzorzec repozytorium w WordPress
Kilka lat temu pisałem o wzorcu repozytorium podając konkretny przykład. To wciąż aktualne, ale cel tego, co chcę omówić w tym poście, jest nieco inny.
Zamiast pokazywać konkretną implementację zakorzenioną w rzeczywistym przykładzie, wolę przedstawić argumenty za tym, jak możemy wykorzystać ten wzorzec w naszej codziennej pracy.
Dwie rzeczy, o których należy pamiętać, czytając to, to:
- z perspektywy użytkownika bazowy magazyn danych nie ma znaczenia,
- z perspektywy programisty wzorzec pozwala nam pracować z wieloma źródłami danych, a także makiety przykładowego magazynu danych, dzięki czemu możemy testować dane.
Przy implementacji wzorca nie ma znaczenia skąd pochodzą dane. Przynajmniej tak długo, jak jesteś deweloperem lub klientem wywołującym go. Magazyn danych może być bazą danych, zestawem funkcji API lub kombinacją obu.
Załóżmy zatem, że pracujesz z niestandardowym typem wpisu dla zdarzeń, a także pracujesz z metadanymi wpisu i opcjami związanymi z czymś takim jak zdarzenia.
Możesz zrobić coś takiego:
- uzyskać nazwę wydarzenia,
- znaleźć informacje o lokalizacji wydarzenia,
- pobierz pierwszy typ posta i status uporządkowany według jego identyfikatora
Wszystkie te informacje mogą być rozproszone w różnych miejscach, a sposób ich pobierania może się różnić.
1 Uzyskiwanie nazwy wydarzenia
Jeśli pracujemy z niestandardowym typem wpisu i potrzebujemy uzyskać nazwę zdarzenia, możemy do tego użyć identyfikatora wpisu i jednej z funkcji API WordPressa.
<?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);
}To jeden z przypadków, w których magazyn danych jest nadal od nas oderwany, a zamiast tego wykorzystuje istniejący WordPress API.
2 Uzyskiwanie lokalizacji wydarzenia
W takim przypadku możemy założyć, że lokalizacja zdarzenia została wprowadzona ręcznie lub być może została pobrana przez interfejs API innej firmy. A ponieważ lokalizacja jest powiązana z konkretnym wydarzeniem, może znajdować się w tabeli metadanych postu.
Ponownie możemy go pobrać za pomocą istniejących wcześniej funkcji API; jednak w takich sytuacjach sensowne jest posiadanie funkcji pomocniczej, ponieważ prawdopodobnie będziemy również uzyskiwać dostęp do innych metadanych.
Więc najpierw pomocnik :
<?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);
}A potem funkcja, która korzysta z pomocnika, aby uzyskać lokalizację :
<?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');
}Ale w tych dwóch przykładach nadal używamy istniejących funkcji API. A co z przypadkiem, w którym musimy porozmawiać z bazą danych?
3 Pobieranie adresu URL pojedynczego posta
W tym przypadku będziemy komunikować się bezpośrednio z bazą danych WordPress. Jeśli znasz obiekt $wpdb i SQL, to nie będzie to wielka sprawa.
Jeśli nie, polecam poczytać o funkcji przygotowania, a także funkcji get_results.
Biorąc to pod uwagę, możemy napisać zapytanie, które wykona następujące czynności:
- weź wszystkie posty, w których identyfikator pasuje do określonej wartości, typ posta i status posta mają określoną wartość, a wyniki uporządkujemy rosnąco według wartości identyfikatora,
- następnie użyjemy wyników tego zapytania, aby uzyskać pojedynczą wartość.
I możemy to zrobić, uzyskując dostęp do bazy danych i pisząc zagnieżdżone zapytanie:
<?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;
}A potem wszystko to można zamknąć w jednej klasie, która byłaby, powiedzmy, repozytorium zdarzeń (lub EventRepository ).
Więcej na ten temat opowiem w kolejnym poście. Mianowicie, jak obsłużyć określić, które funkcje powinny gdzie, konwencje nazewnictwa i jak obsługiwać trwałość, jeśli chcesz wprowadzić to również do swojego repozytorium.
Zdefiniowane repozytorium
Przede wszystkim pamiętaj o tym:
Wzorzec repozytorium maskuje sposób pobierania danych, ale zapewnia spójny sposób pobierania danych, z którymi jest powiązany.
Niektórzy mogą również dodać, jak można to pobrać i jak można to napisać, ale być może omówię to w innym poście.