Wczoraj dałem podkład na temat wzorca repozytorium. Krótko mówiąc, jest to jeden z tych wzorców, który powinien zrozumieć każdy pracujący nad oprogramowaniem pośredniczącym opartym na WordPressie.
Podając podkład na taki wzór, może być trudno oddać sprawiedliwość wzorowi, gdy trzeba:
- przedstaw to,
- wyjaśnij, jak to działa,
- pokryć korzyści,
- i daj małe demo.
Ale prawdziwa zaleta repozytorium polega nie tylko na oddzieleniu warstwy danych od reszty aplikacji, ale także na tym, że może (lub powinna) być łatwo wymieniana z różnymi magazynami danych bez zmiany API.
Na przykład w jednym przypadku może być konieczne pobranie danych z bazy danych WordPress, w innych przypadkach może być konieczne pobranie czegoś z API innej firmy, a może jest jakieś inne miejsce, z którego musisz pobrać dane.
Niezależnie od tego, idea wzorca repozytorium polega na tym, że to, co się za nim znajduje, nie ma znaczenia, o ile udostępniany przez niego interfejs API działa dla warstwy aplikacji, która go wywołuje.
A ponieważ omówiliśmy już elementarz wzorca repozytorium, przyjrzyjmy się niektórym zaletom wzorca repozytorium i sposobom jego implementacji w kontekście projektów WordPress.
Korzyści ze wzorca repozytorium
Jest kilka sposobów na rozpoczęcie wyjaśniania wzoru, więc zacznę od prostego diagramu:
Korzyści ze wzorca repozytorium obejmują abstrakcję magazynu danych
Zauważ, że na powyższym obrazku istnieją trzy główne elementy:
- logika domeny (lub logika biznesowa), którą nazwałem „App",
- repozytorium,
- magazyn danych,
Jeśli chodzi o aplikację, reguły biznesowe zawsze pozostaną względnie spójne. Przynajmniej powinni, prawda?
Repozytorium działa jako środek komunikacji między logiką biznesową a magazynem danych.
Teraz magazynem danych może być baza danych, być może zestaw plików (czego nie polecam), API dla osób trzecich, lista informacji pobranych z innej aplikacji i tak dalej.
Chodzi o to, że repozytorium zapewni czyste API, do którego logika biznesowa może zapisywać i odczytywać (i więcej o tym za chwilę) bez martwienia się o szczegóły, dokąd dane idą lub jak wracają.
To zadanie repozytorium. I właśnie dlatego ważne jest posiadanie spójnego interfejsu API i to jest ważne, aby upewnić się, że zawiera szczegóły implementacji magazynu danych, z którym wchodzi w interakcję.
Na sprzężeniu
Oprócz prawidłowego segmentowania aplikacji, wzorzec repozytorium przynosi korzyści architekturze, ponieważ pomaga oddzielić części aplikacji.
Oznacza to, że logika biznesowa nie wie nic o tym, jak i gdzie przechowywane są dane. Po prostu wie, że może to napisać i pobrać, i może to zrobić za pomocą czystego interfejsu API.
Repozytorium jest odpowiedzialne za komunikację wspomnianego magazynu danych w celu zorganizowania serializacji i pobierania, ale musi zapewniać spójne API, więc warstwa danych nie musi wykonywać żadnej gimnastyki składniowej, aby czytać i zapisywać informacje.
Szczegóły dotyczące wdrożenia
Do tego momentu reprezentowałem repozytorium jako konkretną klasę.
Chodzi o to, że aplikacja prawdopodobnie będzie miała wiele repozytoriów. Z tego powodu dobrym pomysłem jest posiadanie interfejsów, które może zaimplementować każde repozytorium.
W ten sposób definiujesz kontrakt metod, które zapewni repozytorium. W ten sposób możesz upewnić się, że każde repozytorium jest połączone z odpowiednim magazynem danych.
Implementacja interfejsu dla wielu repozytoriów.
Załóżmy więc, że Twoja aplikacja musi komunikować się z bazą danych WordPress, a także z zewnętrznym API.
W idealnym przypadku interfejs zapewniałby wspólny zestaw metod, ale szczegóły implementacji różniłyby się w zależności od repozytorium, ponieważ każde repozytorium będzie miało niezbędne poświadczenia i możliwość komunikacji z magazynem danych.
Jednak postęp w interfejsie jest tym, co nadaje wzorowi moc. Logika domeny nie musi martwić się o sposób zapisywania lub pobierania informacji. Po prostu wywołuje metody zdefiniowane w interfejsie, a niezbędny obiekt się tym zajmuje.
Po prostu wywołuje metody zdefiniowane w interfejsie, a niezbędny obiekt się tym zajmuje.
Jak by to wyglądało w WordPressie?
To jest dobre pytanie (i nie, nie wymyśliłem go tylko po to, żeby samemu odpowiedzieć 🙂), a podanie świetnego przykładu może być trudne, ponieważ wiele z tego, co robimy, oddziałuje bezpośrednio z bazą danych WordPressa.
Nie oznacza to, że nie ma abstrakcji, których możemy użyć, takich jak posty, strony, użytkownicy lub jakiekolwiek inne niestandardowe typy postów, które zdecydujemy się tworzyć.
Ale WordPress zapewnia API do większości z nich. Widzę przypadek, w którym, powiedzmy, użytkownik z dodatkowymi polami, które zostały dodane, mógłby skorzystać z repozytorium użytkowników.
Lub niestandardowy typ postu z dużą ilością metadanych może również skorzystać z repozytorium, ponieważ szczegóły są enkapsulowane w repozytorium.
Przykład wysokiego poziomu
Załóżmy na przykład, że masz niestandardowy typ wpisu dla wydarzenia, a wydarzenie ma tytuł i opis, które naturalnie pasują do tytułu i treści wpisu.
Ale potem ma metadane dotyczące jego lokalizacji, czasu rozpoczęcia, czasu zakończenia i tak dalej. To może być również zamknięte w repozytorium, dzięki czemu można mieć obiekt Event, przekazać go do repozytorium, a następnie pozwolić repozytorium wysłać informacje do odpowiedniego miejsca w bazie danych.
To samo dotyczy pobierania informacji: wie, gdzie je zdobyć, jak wypełnić obiekt Event, a następnie przekazać go z powrotem wywołującemu.
Z powrotem w grze
Ale cała ta rozmowa o wydarzeniu jest trochę nie na temat, więc być może będę nadal mówić o tym i o tym, jak pasuje do repozytorium w kolejnym poście. Oczywiście, mówiąc o tym, jest wiele do omówienia.
Wolałbym robić to małymi krokami
Krótko mówiąc, jeśli masz repozytorium zdarzeń, prawdopodobnie masz obiekt zdarzenia lub encję zdarzenia. A to, jak to pasuje do WordPressa, niestandardowych typów postów, metadanych itd., wprowadza poziom złożoności, który na początku może wydawać się zniechęcający, ale ostatecznie opłaca się podczas pracy z większą aplikacją internetową.