Een bewerking die honderden records wijzigt, kan volgens de regels correct zijn en toch meer gegevens raken dan verwacht. Een algemene bevestiging — ‘Weet u het zeker?’ — maakt het niet mogelijk de reikwijdte te beoordelen of onverwachte omstandigheden op te merken. Een preview van wijzigingen in PHP moet laten zien welke records worden geraakt, welke waarden veranderen en onder welke voorwaarden de bewerking kan worden uitgevoerd.
Een preview vermindert verrassingen, maar garandeert niet dat de latere uitvoering exact hetzelfde resultaat oplevert. Tussen beide fasen kunnen gegevens, rechten of de reikwijdte van de bewerking veranderen. Het ontwerp moet die onzekerheid zichtbaar maken en vóór het schrijven opnieuw valideren wat nodig is.
Wanneer een preview meerwaarde biedt
Een preview is het overwegen waard voor bulkbewerkingen, gevoelige bewerkingen of bewerkingen die moeilijk ongedaan te maken zijn: prijzen bijwerken, statussen wijzigen, accounts opnieuw toewijzen, gegevens verwijderen of afgeleide gegevens opnieuw berekenen. Een preview is ook nuttig wanneer degene die de taak start de impact moet beoordelen of goedkeuring moet krijgen voordat de taak wordt uitgevoerd.
Niet elke actie heeft een previewinterface nodig. Als een bewerking klein en omkeerbaar is en een eenduidig resultaat heeft, kan een contextuele bevestiging volstaan. Als de gebruiker daarentegen niet kan weten wat bevestigen betekent, moet het probleem worden opgelost door concrete gegevens te tonen, niet door nog een dialoogvenster toe te voegen.
Een preview vervangt evenmin een back-up, een rollbackmechanisme of een goedkeuringsbeleid. Als een fout ernstige gevolgen kan hebben, moeten aanvullende controles worden overwogen, zoals goedkeuring door iemand anders, een geleidelijke uitvoering of een getest herstelproces.
Berekening en toepassing scheiden
De bedrijfsregel moet een voorstel kunnen berekenen zonder de database te wijzigen. Een praktische aanpak is om de selectie en berekening te delen tussen twee modi: een modus die de wijziging beschrijft en een modus die deze toepast. Het vermijden van twee afzonderlijke implementaties verkleint het risico dat de preview en de uitvoering verschillende regels interpreteren.
Het voorstel kan voor elk geraakt item het volgende bevatten:
- Een identificatie waarmee het record kan worden herkend.
- De relevante huidige waarden en de verwachte waarden.
- De reden waarom het item wordt opgenomen of uitgesloten.
- De uitgevoerde validaties en de gevonden conflicten.
- De reikwijdte van de bewerking, zoals filters, account of tijdsinterval.
Een bewerking om de status van bestellingen te wijzigen kan bijvoorbeeld de huidige status, de voorgestelde status en de reden waarom een bestelling in aanmerking komt tonen. Als er te veel items zijn om allemaal op het scherm weer te geven, kunnen totalen en een voorbeeld worden getoond. Maak daarbij duidelijk wat er wordt weergegeven en bied de mogelijkheid om de details te inspecteren of te exporteren wanneer dat nodig is.
In PHP is het raadzaam de selectie en berekening onder te brengen in componenten met duidelijke verantwoordelijkheden. Een domeinservice kan voorgestelde wijzigingen opleveren; een ander component kan deze presenteren; en een applicatieroute kan de validatie en opslag verzorgen. De preview mag niet indirect een schrijfopdracht uitvoeren via neveneffecten van het lezen.
Gegevens, rechten en reikwijdte valideren
Een bruikbaar voorstel maakt niet alleen duidelijk wat er zou veranderen, maar ook waarom die wijziging is toegestaan. Valideer de bedrijfsvoorwaarden aan de hand van de huidige gegevens en controleer of de gebruiker toestemming heeft om de bewerking te bekijken en uit te voeren. Toestemming om records te raadplegen betekent niet noodzakelijkerwijs dat de gebruiker ze ook mag wijzigen.
De reikwijdte moet expliciet zijn. Als de actie afhankelijk is van filters, een selectie of een bestandsupload, leg die parameters dan op een begrijpelijke manier vast en communiceer beperkingen, uitsluitingen en fouten. Voorkom dat een brede zoekopdracht of een vergeten filter een beperkte actie per ongeluk verandert in een wijziging voor alle gegevens.
Geef ook aan wat niet met zekerheid kan worden voorspeld. De preview anticipeert niet automatisch op wijzigingen door andere processen, regels die in externe systemen worden uitgevoerd of neveneffecten die afhangen van de toekomstige status. Beschrijf die effecten afzonderlijk als er integraties, wachtrijen of latere berekeningen zijn, en presenteer ze niet als een bevestigd onderdeel van het resultaat.
Voorkomen dat een verouderd voorstel wordt toegepast
Een preview geeft de gegevens op een bepaald moment weer. Als die gegevens vóór de uitvoering veranderen, kan een bestelling niet langer aan de voorwaarden voldoen, kan een gebruiker rechten verliezen of kan een ander proces een record hebben bijgewerkt. Behandel het getoonde resultaat daarom niet als een permanente toestemming om gegevens te schrijven.
Controleer bij de uitvoering opnieuw de voorwaarden die bepalen of een item in aanmerking komt, en controleer de rechten. Afhankelijk van de situatie kun je een recordversie, tijdstempel of relevante waarden vergelijken met de waarden die zijn waargenomen toen het voorstel werd berekend. Pas bij afwijkingen niet stilzwijgend een andere beslissing toe: meld het conflict en vraag om een nieuwe preview te genereren of het conflict expliciet op te lossen.
Bewaar bij processen die een strikte overeenkomst vereisen een verwijzing naar het voorstel en valideer dat de toepassing nog steeds dezelfde reikwijdte en regels gebruikt. Een transactie kan een reeks schrijfbewerkingen beschermen tegen tussentijdse fouten, maar neemt op zichzelf de tijd tussen preview en uitvoering niet weg. De strategie voor gelijktijdigheid moet passen bij het risico en de omvang van de bewerking.
In batches uitvoeren en resultaten vastleggen
Bij grote volumes kan alles in één bewerking toepassen de vergrendelingstijd verlengen en herstel bemoeilijken. Stel batchlimieten vast die passen bij de database en het gedrag van de applicatie. Bij gedeeltelijke fouten moet de gebruiker onderscheid kunnen maken tussen toegepaste records, overgeslagen records en records die moeten worden gecontroleerd.
Leg voldoende informatie vast om het resultaat te onderzoeken: wie de bewerking heeft gestart en goedgekeurd, wanneer deze is voorbereid en uitgevoerd, welke reikwijdte is aangevraagd, hoeveel items zijn verwerkt en welke fouten zijn opgetreden. Sla geen persoonsgegevens of gevoelige waarden op zonder noodzaak; ook auditlogs moeten voldoen aan de toepasselijke toegangs- en bewaarbeperkingen.
Houd rekening met idempotentie als de bewerking opnieuw wordt geprobeerd: het herhalen van een verzoek mag geen onverwachte effecten dupliceren. Een bewerkings-ID en uitvoeringsstatussen kunnen helpen herhaalde verzoeken te herkennen en voorbereiding, goedkeuring, uitvoering en afronding van elkaar te onderscheiden. Presenteer de deployment van de code niet als gelijkwaardig aan het vrijgeven of inschakelen van de bewerking: dat zijn afzonderlijke beslissingen waarvoor eigen controles nodig zijn.
Testen of de preview geen gegevens wijzigt
Tests moeten zowel de berekening als de afwezigheid van schrijfbewerkingen in de previewmodus controleren. Gebruik representatieve gegevens om te controleren welke items worden opgenomen en uitgesloten, wat de huidige en voorgestelde waarden zijn, en hoe onvoldoende rechten en mislukte validaties worden afgehandeld.
Controleer ook of de uitvoering het verwachte voorstel toepast en of gelijktijdige wijzigingen het gedefinieerde gedrag opleveren. Test fouten binnen een batch, nieuwe pogingen en integratiefouten waar dat van toepassing is. Integratietests met de database zijn belangrijk: een unit-test van de berekening bewijst niet dat een previewroute geen neveneffecten heeft.
Randgevallen moeten lege filters, grote volumes, records die tussen de fasen zijn verwijderd of gewijzigd, en gebruikers met verschillende toegangsbereiken omvatten. Controleer ook of de interface niet beweert dat ‘precies deze items worden bijgewerkt’ als de toepassing de set op het moment van uitvoering opnieuw berekent.
Checklist om te bepalen welke controle nodig is
- Raakt de bewerking veel records, zijn de effecten moeilijk ongedaan te maken of is goedkeuring vereist?
- Worden de reikwijdte, de geraakte items en de huidige en verwachte waarden getoond?
- Is de preview gescheiden van schrijfbewerkingen en hun neveneffecten?
- Worden rechten, bedrijfsregels en gegevens zowel bij de voorbereiding als bij de uitvoering gevalideerd?
- Worden relevante wijzigingen tussen beide fasen gedetecteerd?
- Zijn er batchlimieten, een vastgelegde aanpak voor gedeeltelijke fouten en passende auditlogs?
- Bevestigen de tests dat een preview geen gegevens wijzigt en dat de uitvoering het gevalideerde resultaat respecteert?
Een preview is geschikt wanneer deze helpt om een weloverwogen beslissing te nemen en de beperkingen ervan duidelijk zijn. Als de impact niet betrouwbaar kan worden ingeschat, is het beter de reikwijdte te verkleinen, eerst in een gecontroleerde omgeving uit te voeren of een aanvullende beoordeling te vereisen, in plaats van een getal of gedeeltelijke lijst als resultaatgarantie voor te stellen.
