Databasfrågor för att snabbt uppdatera data, del 2
Detta är den andra, och sista delen, i en serie om – som titeln antyder – direkta databasfrågor. Specifikt handlar det om att ändra inläggsstatus (men det är relevant för mer än så).
Foto av Ross Findon på Unsplash
Detta är ännu ett inlägg som kommer att vara en illustration av hur man använder $wpdb för att snabbt uppdatera information baserat på metadata.
Och koden i det inlägget fungerar men om du vill göra den mer objektorienterad finns det mer arbete som kan göras.
Innan du hoppar in i själva inlägget är det dock viktigt att notera att när det kommer till objektorienterad programmering, finns det mycket arbete som kan läggas ner på klassdesignen och skapa abstraktionsnivåer.
Vid något tillfälle måste du dra den ökända gränsen mellan när du ska använda gränssnitt, hur granulära dina klasser kommer att vara i termer av vad de abstraherar och liknande.
Och syftet med det här inlägget är att hjälpa till att ge en bättre objektorienterad design men det är inte en övning som gör detta så optimalt som möjligt. Jag diskuterar sådana här ämnen i en annan serie inlägg.
Men tänk på det när du läser igenom koden under resten av inlägget.
Databasfrågor för att snabbt uppdatera data, del 2
Med tanke på var vi slutade har vi en enda funktion som gör följande:
- hämta alla inlägg som är associerade med en specifik metanyckel,
- avgöra om vi behöver lämna tidigt,
- uppdatera inläggsstatusen för alla befintliga inlägg.
Det första att notera är att en enskild funktion är för mycket, så den måste delas upp i flera andra funktioner. Och eftersom det är objektorienterat måste vi se till att vad en funktion än gör inte nödvändigtvis baseras på tidigare steg – det är precis vad procedurprogrammering handlar om.
Istället kommer vi att använda den här möjligheten för att ställa in funktioner, så att de fungerar på vilken data som skickas till dem oavsett hur de kom dit.
Slutligen är det upp till dig, som utvecklare, att avgöra om du vill ha en enda klass för att göra detta, mer än en klass, eller ha en uppsättning relaterade klasser som ärver från en överordnad klass.
Återigen, det handlar om hur abstrakt du vill göra koden.
För nu, men låt oss gå vidare med att bryta upp saker.
1 Ta tag i inläggs-ID:n med den associerade metanyckeln
Precis som i det första inlägget vill vi se till att vi hämtar inläggs-ID:n som är relaterade till en specifik metanyckel.
För att göra den här funktionen så flexibel som möjligt ställer vi in den till:
- acceptera meta-nyckeln som en sträng,
- returnera en array
Funktionen kommer då att se ut ungefär så här:
I det första inlägget delade vi upp detta i tre steg (som också beskrivs ovan). Här kan vi dock kombinera det andra och tredje steget till en enda funktion.
2 Uppdatera poststatus
Som jag nämnde är den ena aspekten av objektorienterad programmering att se till att funktionerna vi använder är agnostiska om hur data genererades som de tar emot.
Istället har de en enda algoritm att köra för att fokusera på data som skickas till funktionen. I det här fallet vill vi ta uppsättningen resultat – som är inläggs-ID:n – och uppdatera deras inläggsstatus så att den är inställd på utkast.
Detta innebär att funktionen accepterar en array men inte returnerar något. Potentiellt skulle du kunna låta den hålla reda på många inlägg som den uppdaterade (eller om den uppdaterade något alls), men jag är fokuserad på att bara omstrukturera koden vi redan har.
Så det är vad vi ska göra. Och det första är att se till att det finns faktiska data att arbeta med. Och om så är fallet, iterera genom listan med inläggs-ID:n och ändra deras inläggsstatus:
Du kan se att det inte skiljer sig mycket från det arbete som har gjorts i det första inlägget, men det väcker nu några frågor.
3 Objektorienterade överväganden
När du arbetar med kod så här:
- Hör allt hemma i samma klass eller separata klasser?
- Ska det finnas en basklass och i så fall varför eller varför inte?
- Bör det finnas en enda offentlig funktion som anropas som anropar dessa metoder (och har dem markerade som privata)?
- Ska vi lämna funktionerna offentliga?
För det här inlägget kommer jag att göra följande:
- Exponera varje funktion som en offentlig metod. Detta är så att om det finns data som returneras från den första metoden, kan du potentiellt göra något annat med den.
- Håll det i en enda klass. På så sätt kan vi instansiera en enskild klass och sedan använda den för att göra allt vi behöver göra. Om det fanns andra metoder skulle vi använda samma metoder.
- Börja med gränssnittet. Jag tänker inte bry mig om att skriva ett gränssnitt i syfte att bara visa ett gränssnitt (jag antar att det är lätt nog att härleda med tanke på de funktioner vi har just nu), men jag ska ta klassen och visa hur vi kan åberopa fungerar "från utsidan och in".
Så jag ska börja med den sista punkten och jobba baklänges. Här är ett sätt att arbeta med koden:
Och så här ser hela klassen ut:
Generellt sett kommer det att tjäna samma syften som de första men på ett mer objektorienterat sätt.
Det är inte vägen
Eftersom jag har försökt upprepa flera gånger genom det här inlägget, är detta inte det definitiva sättet att göra detta arbete. Istället är det ett sätt att arbeta på.
Du kan designa om, re-faktorera eller återanvända detta hur du vill. Syftet är dock att visa hur man kopplar bort logik som vi normalt ser som processuell till något som är lite mindre beroende av sig själv och lämnar utrymme för ytterligare arbete.