Repository Pattern Primer
Närhelst du arbetar med ett större projekt som är baserat på WordPress, är oddsen att du kommer att arbeta med mer än en enda datakälla – det vill säga WordPress-databasen – högre än normalt. Du kanske till exempel arbetar med ett projekt som måste koordinera information från:
- WordPress-databasen,
- ett hjälpdesk biljettsystem,
- ett innehållsimporteringssystem,
- ett annat API från tredje part,
- och möjligt mer.
Och när detta händer kan det bli lite krångligt att skriva kod som gör det enkelt att hämta information från de olika platserna. Det här brukar utvecklare prata om när de hänvisar till att hantera "lager" i sin applikation. Det vill säga,
- det finns lager för att presentera information för användaren,
lager för att hantera affärslogik (eller domänlogik), - lager för att kommunicera med API:er,
- och lager för att lagra data.
Ärligt talat behöver du inte ha en mängd olika datalager att titta på för att skapa ett lager som gör det lättare att skicka och hämta data från databasen, det är just då det är vanligare. Du kan lika effektivt arbeta med ett enda datalager, som WordPress-databasen, när du implementerar förvarsmönstret.
Oavsett, om du bygger en större webbplats, webbapplikation eller plugin, är implementering av förvarsmönstret något som kan ge utdelning i underhåll, tydlig kod och separation av problem.
Men hur kan detta implementeras i WordPress? Det är inte särskilt utmanande, men först är det värt att granska en repository primer innan du hoppar in i någon kod.
En förvarsmönsterprimer
Innan du tittar på en faktisk implementering i WordPress är det viktigt att förstå vad förvaret är, hur det definieras, vad det erbjuder och en generisk implementering av det. Jag kommer att dela lite mer läsning i slutet av artikeln, men tills dess kommer jag att täcka min allmänna syn på mönstret här.
För det första kan en implementering av detta mönster bli mer komplicerad än nödvändigt för nybörjare. Därmed inte sagt att det faktiska mönstret inte är värt att förstå, men om du bara är ute efter att bli blöt med det här, är jag inte ett fan av att kasta in läsarna i den djupa delen. Jag tror inte att det är det bästa sättet att lära sig.
Istället är det värt att bryta ner problemet och sedan bygga om det till något lite mer elegant. Så det är vad jag ska sikta på att göra.
Ett ord om frikoppling
När vi pratar om objektorienterad programmering pratar vi ofta om idén att "frikoppla" delar av systemet. Om du är bekant med koppling och sammanhållning, då vet du varför.
Men om inte, räcker det med att säga att ju mer kopplade komponenterna ditt system är, desto svårare är de att ändra. De vet för mycket om varandra. Det vill säga, om du ändrar en av aspekterna av systemet, kommer det sannolikt att överlappa eller påverka en annan del av systemet som du aldrig menade skulle hända. Då är du kvar när du måste lägga mycket mer tid på att fixa alla dessa andra "beröringspunkter" i systemet som inte borde vara nödvändiga.
Implementering av olika strategier, som förvarsmönstret, kan hjälpa till att frikoppla delar av systemet. Exempel: Presentationsskiktet vet inte hur den underliggande datalagringen är organisation. Den behöver inte kunna SQL. Det behöver inte veta att det är en databas. Istället behöver den bara veta hur man pratar med förvaret.
Trevligt, eller hur?
Detta innebär att du kan byta ut backend-datalagret och, förutsatt att ditt API är stabilt; din applikation kommer att fortsätta att fungera med liten eller ingen förändring. Och det är vad det innebär att verkligen vara frikopplad.
En implementering av förvarsmönstret
Så hur ser förvarsmönstret ut? Som med de flesta designmönster finns det en generisk form av mönstret, och det är alltid användbart, men jag tror att det också hjälper oss som arbetar i WordPress att se hur det kan fungera inom ramen för, du vet, WordPress.
Så först vill jag bryta ner själva mönstret och sedan ge ett exempel på hur det kan se ut när man arbetar med WordPress.
En generisk implementering av förvarsmönstret
Den faktiska implementeringen av förvarsmönstret är ganska enkel. Jag är faktiskt aldrig säker på om det är så användbart eftersom det bara visar hur datalagren, förvaret och resten av applikationen interagerar med varandra.
Missförstå mig rätt: jag är helt för konceptuella modeller av hur saker är organiserade. Personligen hjälper det mig att tänka på strukturen för en applikation när jag bygger den, men om den är för allmän är det inte mycket hjälp.
Men för att komma till ett konkret redskap måste vi väl börja någonstans? Så jag börjar på högsta möjliga nivå och jobbar neråt.
Som du kan se på bilden ovan har du ett par datalager som alla läses via förvaret, och sedan frågar applikationen ut förrådet som i sin tur hämtar information från datalagret.
Ja, det finns alternativ för att cache-information, ogiltigförklara cachen och allt det där roliga. Men det ligger utanför omfattningen av en primär av förvaret. Så jag tänker inte gå in på just den vägen just nu. Kanske i ett framtida inlägg (skulle detta visa sig vara användbart för dig).
Förvarsmönstret i WordPress
Så med det sagt, låt oss ta en titt på en grundläggande implementering av hur detta kan se ut i en standard WordPress-installation. Det vill säga, allt vi har är datalagret. Vi kommunicerar inte med något annat, men vi vill se till att allt som gränssnitt mot databasen eller API:t hanteras av förvaret
Det här skulle se ut ungefär så här:
Hur det kan se ut med WordPress
Och detta kan abstraheras ytterligare. Kanske finns det ett postförråd eller ett användarförråd. Personligen är jag ett fan av att ha ett arkiv för varje typ av entitet eftersom det hjälper till att innehålla relaterad affärslogik utan att skapa de där stora klasserna som vet allt (och i onödan).
Så det här kan se ut så här:
Ett paket med förråd
Låt oss sedan ta det upp en nivå till och säga att du arbetar med Twitter API, ZenDesk API, WordPress User API och WordPress Post API. Sen då? Det finns fler förråd.
Kanske finns de i deras namnutrymme (vilket de borde vara), kanske implementerar de ett gemensamt gränssnitt (som det finns skäl för detta), men under utvecklingstiden tror jag att det är viktigt att uttryckligen ange vilket arkiv du använder för att vara så tydlig som möjligt.
Det vill säga, använd inte en generisk och låt runtime ta reda på det:
$support_repository = new Support_Repository();
$support_repository->get_tickets_for( 'tommcfarlin' );Var i stället tydlig:
$zendesk_repository = new ZenDesk_Repository();
$zendesk_repository->get_tickets_from( 'yesterday' );Det här kan kännas mycket. Jag vet inte om du upplever detta, men det finns en konstig känsla i objektorienterad programmering där vi vill skapa de små fokuserade klasserna men det skapar många filer.
Så du har dessa snyggt inställda filer som var och en gör något litet och målmedvetet. Låt inte antalet filer som utgör ett projekt ge intryck av att du har en dålig arkitektur.
Slutsats
Detta är primern på förvarsmönstret. Naturligtvis finns det kod som hör ihop med detta, men innan jag dyker in i den delen – eftersom kod är där saker som lätt försvinner i översättning – ville jag vara säker på att jag hjälpte till att ge en illustration för att utveckla en konceptuell modell för hur mönstret fungerar.
Härifrån kan vi börja prata om en implementering av mönstret. Så under nästa inlägg eller nästa par inlägg kommer jag att göra precis det.
Under tiden, tveka inte att lämna några kommentarer eller frågor om vad som har tagits upp här.