Fördelar med förvarsmönster: Varför vi bör överväga det
Igår gav jag en primer på förvarsmönstret. Kort sagt, det är ett av de mönster som jag tror att alla som arbetar med mellanprogram byggd ovanpå WordPress borde förstå.
När du ger en primer på ett mönster som detta kan det vara svårt att göra rättvisa åt mönstret när du behöver:
- introducera det,
- förklara hur det fungerar,
- täcka förmånerna,
- och ge en liten demo.
Men den verkliga fördelen med förvaret ligger inte bara i att abstrahera datalagret bort från resten av applikationen utan att det enkelt kan (eller borde) kunna bytas ut med olika datalager utan att ändra API:et.
Till exempel, i ett fall kan du behöva hämta data från WordPress-databasen, i andra fall kan du behöva hämta något från ett tredjeparts-API, eller kanske finns det någon annan plats där du behöver hämta data.
Oavsett vilket är tanken bakom förvarsmönstret att vad som än sitter bakom det inte spelar någon roll så länge som API:et det tillhandahåller fungerar för lagret i applikationen som anropar det.
Och eftersom vi har täckt en primer om förvarsmönstret, låt oss ta en titt på några av förvarsmönstrets fördelar och hur vi kan implementera det i samband med WordPress-projekt.
Fördelar med förvarsmönster
Det finns några sätt att börja förklara mönstret, så jag börjar med ett enkelt diagram:
Fördelarna med förvarsmönster inkluderar Data Store Abstraktion
Observera i bilden ovan, det finns tre huvudkomponenter:
- domänlogiken (eller affärslogiken) som jag har märkt "App",
- förvaret,
- datalagret,
När det gäller tillämpningen kommer affärsreglerna alltid att vara relativt konsekventa. Det borde de åtminstone, eller hur?
Förvaret är det som fungerar som ett kommunikationsmedel mellan affärslogiken och datalagret.
Nu kan datalagret vara en databas, kanske en uppsättning filer (vilket jag inte skulle rekommendera), ett API till en tredje part, en lista med information hämtad från en annan applikation, och så vidare.
Poängen är att förvaret kommer att tillhandahålla ett rent API som affärslogiken kan skriva till och läsa från (och mer om detta på ett ögonblick) utan att oroa sig för detaljerna om vart data är på väg eller hur den kommer tillbaka.
Det är förvarets uppgift. Och det är det som gör det viktigt att ha ett konsekvent API och det är det som är viktigt för att se till att det har implementeringsdetaljerna för det datalager som det interagerar med.
På koppling
Förutom att ha din applikation ordentligt segmenterad, gynnar förvarsmönstret arkitekturen genom att det hjälper till att frikoppla delarna av din applikation.
Det vill säga, affärslogiken vet ingenting om hur eller var data lagras. Det vet bara att det kan skriva det och hämta det och det kan göra det med ett rent API.
Lagret är ansvarigt för att kommunicera nämnda datalager för att organisera serialisering och hämtning men måste tillhandahålla ett konsekvent API, så datalagret behöver inte göra någon syntaxgymnastik för att läsa och skriva sin information.
Implementeringsdetaljer
Fram till denna punkt har jag representerat förvaret som en betongklass.
Saken är att en applikation sannolikt kommer att ha flera arkiv. Och på grund av det är det en bra idé att ha gränssnitt som varje arkiv kan implementera.
Så här definierar du kontraktet med metoder som förvaret ska tillhandahålla. Och så här kan du säkerställa att varje förråd är anslutet till rätt datalager.
En gränssnittsimplementering för flera arkiv.
Så låt oss säga att din applikation behöver prata med WordPress-databasen såväl som ett tredjeparts-API.
Helst skulle gränssnittet tillhandahålla en gemensam uppsättning metoder, men implementeringsdetaljerna skulle variera beroende på lagringsplats eftersom varje arkiv kommer att ha de nödvändiga referenserna och förmågan att kommunicera med datalagret.
Framsteg till gränssnittet är dock det som ger mönstret dess kraft. Domänlogiken behöver inte oroa sig för hur informationen sparas eller hur den hämtas. Det anropar helt enkelt metoderna som definieras i gränssnittet och det nödvändiga objektet tar hand om det.
Det anropar helt enkelt metoderna som definieras i gränssnittet och det nödvändiga objektet tar hand om det.
Hur skulle detta se ut i WordPress?
Det här är en bra fråga (och nej, jag hittade inte på den bara för att svara på den på egen hand 🙂), och det kan vara svårt att ge ett bra exempel eftersom så mycket av det vi gör interagerar direkt med WordPress-databasen.
Det betyder inte att det inte finns abstraktioner som vi kan använda såsom inlägg, sidor, användare eller andra anpassade inläggstyper vi väljer att skapa.
Men WordPress tillhandahåller ett API för mycket av detta. Jag kan se ett fall där, säg, en användare med ytterligare fält som har lagts till kan dra nytta av ett User Repository.
Eller en anpassad posttyp med mycket metadata kan också dra nytta av ett arkiv genom att ha detaljerna inkapslade i arkivet.
Ett exempel på hög nivå
Säg till exempel att du har en anpassad inläggstyp för en händelse, och händelsen har en titel och beskrivning som naturligt skulle passa in i inläggets titel och innehåll.
Men sedan har den metadata om sin plats, sin starttid, sin sluttid och så vidare. Det kan också vara inkapslat av förvaret så att du kan ha ett Event-objekt, skicka det till förvaret och sedan låta förvaret skicka informationen till rätt plats i databasen.
Och detsamma gäller för att hämta informationen: Den vet var den ska hämtas, hur man fyller i ett händelseobjekt och sedan lämnar tillbaka den till den som ringer.
Tillbaka på banan
Men allt det här snacket om en händelse börjar bli lite utanför ämnet, så jag kanske fortsätter att prata om det och hur det passar in i förvaret i ett uppföljande inlägg. Det är uppenbart att när man pratar om detta finns det mycket att ta upp.
Jag tar det hellre i mindre steg
Kort sagt, om du har ett Event Repository har du sannolikt ett Event-objekt eller en Event-enhet. Och hur detta passar in i WordPress, anpassade inläggstyper, metadata och så vidare introducerar en komplexitetsnivå som kan verka skrämmande till en början men som i slutändan lönar sig när man arbetar med en större webbapplikation.