Za każdym razem, gdy pracujesz nad większym projektem opartym na WordPressie, szanse, że będziesz pracować z więcej niż jednym źródłem danych – czyli bazą danych WordPress – są wyższe niż normalnie. Na przykład możesz pracować nad projektem, który musi koordynować informacje z:
- baza danych WordPress,
- system biletowy help desk,
- system importu treści,
- inny API innej firmy,
- i możliwe więcej.
A kiedy tak się dzieje, pisanie kodu, który ułatwia pobieranie informacji z tych różnych miejsc, może być nieco kłopotliwe. To, o czym zwykle mówią programiści, gdy odnoszą się do „warstw" w swojej aplikacji.
- istnieją warstwy do prezentacji informacji użytkownikowi,
warstwy do obsługi logiki biznesowej (lub logiki domenowej), - warstwy do komunikacji z API,
- oraz warstwy do przechowywania danych.
Szczerze mówiąc, nie musisz mieć różnych magazynów danych do oglądania, aby utworzyć warstwę, która ułatwia wysyłanie i pobieranie danych z bazy danych, to tylko wtedy, gdy jest to bardziej powszechne. Równie skutecznie możesz pracować z pojedynczym magazynem danych, takim jak baza danych WordPress, wdrażając wzorzec repozytorium.
Niezależnie od tego, czy budujesz większą witrynę, aplikację internetową lub wtyczkę, implementacja wzorca repozytorium jest czymś, co może przynieść zyski w utrzymaniu, przejrzystości kodu i oddzieleniu obaw.
Ale jak można to zaimplementować w WordPressie? Nie jest to trudne, ale najpierw warto przejrzeć elementarz repozytorium przed przejściem do jakiegokolwiek kodu.
Podkład wzorca repozytorium
Zanim przyjrzymy się rzeczywistej implementacji w WordPress, ważne jest, aby zrozumieć, czym jest repozytorium, jak jest zdefiniowane, co oferuje i jaka jest jego ogólna implementacja. Podzielę się dalszą lekturą na końcu artykułu, ale do tego czasu omówię tutaj moje ogólne podejście do wzoru.
Po pierwsze, implementacja tego wzorca może stać się bardziej skomplikowana niż jest to konieczne dla początkujących. Nie oznacza to, że rzeczywisty wzór nie jest wart zrozumienia, ale jeśli chcesz się z tym po prostu zmoczyć, nie jestem fanem rzucania czytelników na głęboką wodę. Nie sądzę, że to najlepszy sposób na naukę.
Zamiast tego warto przełamać problem, a następnie przebudować go na coś bardziej eleganckiego. Więc to właśnie zamierzam zrobić.
Słowo o oddzieleniu
Mówiąc o programowaniu obiektowym, często mówimy o idei „odsprzęgania” części systemu. Jeśli znasz się na sprzężeniu i spójności, wiesz dlaczego.
Ale jeśli nie, wystarczy powiedzieć, że im bardziej sprzężone są komponenty twojego systemu, tym trudniej je zmienić. Za dużo o sobie wiedzą. Oznacza to, że jeśli zmienisz jeden z aspektów systemu, prawdopodobnie wpłynie to kaskadowo lub wpłynie na inną część systemu, której nigdy nie miałeś zamiaru wydarzyć. Wtedy pozostajesz, gdy musisz spędzać znacznie więcej czasu na naprawieniu wszystkich innych „punktów styku” w całym systemie, które nie powinny być konieczne.
Wdrażanie różnych strategii, takich jak wzorzec repozytorium, może pomóc w rozdzieleniu części systemu. Przykład: warstwa prezentacji nie wie, jak zorganizowany jest bazowy magazyn danych. Nie musi znać SQL. Nie musi wiedzieć, że to baza danych. Zamiast tego musi tylko wiedzieć, jak rozmawiać z repozytorium.
Ładne, prawda?
Oznacza to, że możesz wymienić magazyn danych zaplecza i zakładając, że Twój interfejs API jest solidny; Twoja aplikacja będzie nadal działać bez zmian. I to właśnie oznacza bycie naprawdę oddzielonym.
Implementacja wzorca repozytorium
Jak więc wygląda wzorzec repozytorium? Podobnie jak w przypadku większości wzorców projektowych, istnieje ogólna forma wzorca, która zawsze jest pomocna, ale myślę, że pomaga również tym z nas, którzy pracują nad WordPressem, zobaczyć, jak może działać w kontekście, wiesz, WordPressa.
Więc najpierw chcę rozbić sam wzorzec, a następnie podać przykład, jak może wyglądać podczas pracy z WordPressem.
Ogólna implementacja wzorca repozytorium
Rzeczywista implementacja wzorca repozytorium jest dość prosta. W rzeczywistości nigdy nie jestem pewien, czy jest to tak pomocne, ponieważ pokazuje tylko, w jaki sposób magazyny danych, repozytorium i reszta aplikacji współdziałają ze sobą.
Nie zrozum mnie źle: jestem za koncepcyjnymi modelami tego, jak rzeczy są zorganizowane. Osobiście pomaga mi myśleć o strukturze aplikacji podczas jej budowania, ale jeśli jest zbyt ogólna, to niewiele pomaga.
Ale żeby dostać się do konkretnego narzędzia, musimy gdzieś zacząć, prawda? Więc zacznę od najwyższego możliwego poziomu i będę pracować w dół.
Jak widać na powyższym obrazku, masz kilka magazynów danych, z których wszystkie są odczytywane przez repozytorium, a następnie aplikacja wysyła zapytanie do repozytorium, które z kolei pobiera informacje z magazynu danych.
Tak, istnieją opcje buforowania informacji, unieważniania pamięci podręcznej i wszystkich tych zabawnych rzeczy. Ale jest poza zakresem głównego repozytorium. Więc na razie nie zamierzam iść tą konkretną ścieżką. Być może w przyszłym poście (jeśli ten okaże się dla Ciebie przydatny).
Wzorzec repozytorium w WordPress
Mając to na uwadze, przyjrzyjmy się podstawowej implementacji tego, jak może to wyglądać w standardowej instalacji WordPressa. Oznacza to, że wszystko, co mamy, to magazyn danych. Nie komunikujemy się z niczym innym, ale chcemy mieć pewność, że wszystko, co łączy się z bazą danych lub API, jest obsługiwane przez repozytorium
Wyglądałoby to mniej więcej tak:
Jak to może wyglądać z WordPress
I można to jeszcze bardziej wyabstrahować. Być może istnieje repozytorium postów lub repozytorium użytkowników. Osobiście jestem fanem posiadania repozytorium dla każdego typu encji, ponieważ pomaga to zawierać powiązaną logikę biznesową bez tworzenia tych dużych klas, które wiedzą wszystko (i niepotrzebnie).
Może to wyglądać tak:
Pakiet repozytoriów
Następnie weźmy jeszcze jeden poziom i powiedzmy, że pracujesz z API Twittera, ZenDesk API, WordPress User API i WordPress Post API. Co wtedy? Jest więcej repozytoriów.
Być może są one zawarte w ich przestrzeni nazw (którą powinny być), może implementują wspólny interfejs (na co jest ku temu powód), ale w czasie tworzenia uważam, że ważne jest, aby wyraźnie określić, którego repozytorium używasz tak, aby być tak jasnym, jak to możliwe.
Oznacza to, że nie używaj generycznego i pozwól środowisku wykonawczemu to rozgryźć:
$support_repository = new Support_Repository();
$support_repository->get_tickets_for( 'tommcfarlin' );Zamiast tego bądź wyraźny:
$zendesk_repository = new ZenDesk_Repository();
$zendesk_repository->get_tickets_from( 'yesterday' );To może wydawać się dużo. Nie wiem, czy tego doświadczasz, ale jest dziwne uczucie w programowaniu obiektowym, gdzie chcemy tworzyć małe, skoncentrowane klasy, ale tworzy wiele plików.
Masz więc te starannie skonfigurowane pliki, z których każdy robi coś małego i celowego. Nie pozwól, aby liczba plików składających się na projekt sprawiała wrażenie, że masz słabą architekturę.
Wniosek
To jest podkład do wzorca repozytorium. Oczywiście istnieje kod, który się z tym zgadza, ale zanim zagłębię się w tę część – ponieważ kod jest miejscem, w którym łatwo giną rzeczy w tłumaczeniu – chciałem się upewnić, że pomogłem dostarczyć ilustrację do opracowania modelu koncepcyjnego działania wzorca.
Od tego momentu możemy zacząć mówić o implementacji wzorca. Więc w następnym poście lub kilku następnych postach zamierzam to zrobić.
W międzyczasie nie wahaj się zostawiać żadnych komentarzy lub pytań dotyczących tego, co tutaj omówiliśmy.
Powiązane czytanie
- Wzorzec repozytorium za pośrednictwem ósmego światła
- Wzorzec repozytorium za pośrednictwem MSDN
- Implementacja wzorca repozytorium