In het verleden heb ik wel eens een vergelijkbare vraag gesteld, maar ik ben benieuwd hoe jullie er vandaag de dag tegenover staan.
De vraag luidt: wat controleer jij?
Ik zag zojuist in een ander topic dat iemand alvorens een view te includen ging controleren of de view wel bestaat. Op zich niks mis mee, maar hoe ver ga jij hierin? Controleer jij ALTIJD of een bestand aanwezig is alvorens je het gaat parsen of laden? Ook als je zeker weet dat dat bestand gewoon altijd aanwezig is? En wat doe je met bijv. met configuratiesettings die je ophaalt op basis van hun ID? Haal je die gelijk op omdat je weet dat de setting bestaat? Of controleert jouw get() functie stiekem nog even of je wel een geldige ID hebt ingegeven?
Wat van buiten komt, controleer je natuurlijk altijd.
Intern voer je een controle alleen uit wanneer dat meer oplevert dan kost. Een baten/lasten-verhouding is er meestal wel ergens.
Als je elke require bijvoorbeeld in een file_exists() verpakt, verdubbel je het aantal uitstapjes naar het file system. Dat zijn de kosten/lasten. Kun je vervolgens niets zonder vereist bestand, dan zijn de opbrengsten/baten nul. Einde van de vergelijking is dan dat het niets oplevert en alleen maar iets kost en dan doe je dat dus niet.
Zo'n vergelijking kan natuurlijk ook anders uitpakken. Bijvoorbeeld een uitstapje naar een database heeft vrij hoge kosten/lasten. Dan levert het al gauw meer op om eerst even te controleren of een ID die je in een query stopt wel voldoet aan de ID's in het datamodel.
>> Kun je vervolgens niets zonder vereist bestand, dan zijn de opbrengsten/baten nul.
Oké, en in zo'n geval gebruik jij dan neem ik aan gewoon een require die uitmondt in een fatal error als het bestand niet bestaat?
@Michael:
>> Alles wat dynamisch is controleren (get,post,etc) alles wat statisch (include,etc) is zou niet nodig hoeven zijn.
Oké. Dat lijkt mij inderdaad een mooie stelregel. Maar ik zie dus heel vaak code voorbijkomen waarin bijv. wordt gecontroleerd of een bepaalde view wel bestaat. Als je uitgaat van een MVC model, dan controleer je eerst of iemand een geldige route heeft aangeroepen. Als de route (URL) klopt, dan hoef je vervolgens toch niet ook nog eens te controleren of de view wel bestaat?
>> Kun je vervolgens niets zonder vereist bestand, dan zijn de opbrengsten/baten nul.
Oké, en in zo'n geval gebruik jij dan neem ik aan gewoon een require die uitmondt in een fatal error als het bestand niet bestaat?
Inderdaad. Moet je maar opletten bij het uploaden. Required betekent immers: vereist.
Er zijn overigens frameworks die precies het tegenovergestelde doen. Die gebruiken een view, een controller, een plug-in en zelfs een template of een afbeelding wanneer die aanwezig is in de daarvoor bestemde directory. Ze implementeren dus via file_exists() een omgekeerde beslissingsregel: is het geïnstalleerd, dan moet het kennelijk worden gebruikt.
Lijkt mij niet handig of verstandig, want zo bouw je een kaartenhuis dat volledig afhankelijk is van de directory- en bestandsstructuur.
Ik ben dan wel nog even benieuwd hè... met mijn filesystem class kan ik een bestand laden (via file_get_contents). Nu check ik dus in die load() method eerst of het bestand bestaat. Zo niet dan gooi ik een exception. Dit had ik ingebouwd omdat mijn filecacher gebruik maakt van het filesystem. Als ik dan een bestand wil loaden en het bestaat niet, gooit het filesystem een exception. Nu zit ik me dus af te vragen of ik de verantwoordelijkheid niet moet verplaatsen. De controle weghalen uit de load() method van het filesystem en in plaats daarvan een is_file() toepassen in de load() method van de cacher. Wat vind jij? Normaal gesproken kan het toch niet gebeuren dat een bestand zomaar van de server verdwijnt? Of kan zoiets in uitzonderlijke gevallen wel gebeuren door een hick-up van de server of iets dergelijks?
Ik zou de file cacher rechtstreeks loslaten op bestanden en er geen filesystem-klasse tussen zetten. Of meer precies: de file cacher direct de verantwoordelijkheid geven over de eigen cachedirectory en je filesystem gebruiken voor al het andere.
Als ik het zo lees, is je filesystem-klasse weinig meer dan een OOP-wrapper voor PHP-functies. Dat voegt alleen overhead toe die je juist bij een cache niet wilt.
Ja, is een overweging. Maar waar gebruik je in de praktijk dan een filesystem voor? Mijn filesystem kan wel een complete directory verwijderen. Als ik dat zou inbouwen in de filecacher dan ben ik code aan het kopiëren en dat is ook niet helemaal juist. Maar het is iets om over na te denken.
Maar mijn andere vraag... is het mogelijk dat een bestand zomaar ineens van de server verdwijnt? Niet omdat je het bestand zelf hebt verwijderd (hetzij handmatig of dmv code) maar echt buiten jouw "schuld" om. Kan een bestand zomaar ineens verdwijnen? Bijv. omdat de server een hick-up heeft? Of komt zoiets nooit voor?
Maar mijn andere vraag... is het mogelijk dat een bestand zomaar ineens van de server verdwijnt? Niet omdat je het bestand zelf hebt verwijderd (hetzij handmatig of dmv code) maar echt buiten jouw "schuld" om. Kan een bestand zomaar ineens verdwijnen? Bijv. omdat de server een hick-up heeft? Of komt zoiets nooit voor?
Er zijn natuurlijk altijd wel situatie te bedenken. Zo was er bij mijn hosting laatst een probleem opgetreden waarbij ze een backup moesten terug zetten, maar deze backups bleken corrupt te zijn waar door een oudere backup werd terug gezet. Als ik dan een dag voor dat probleem een bestand erop had gezet, was ie niet meer te vinden. Je kunt je afvragen hoe vaak dit voorkomt en of dit een probleem is.
Maar mijn andere vraag... is het mogelijk dat een bestand zomaar ineens van de server verdwijnt? Niet omdat je het bestand zelf hebt verwijderd (hetzij handmatig of dmv code) maar echt buiten jouw "schuld" om. Kan een bestand zomaar ineens verdwijnen? Bijv. omdat de server een hick-up heeft? Of komt zoiets nooit voor?
Ja, bijvoorbeeld bij een beschadigde schijf kunnen bestanden corrupt en daardoor onleesbaar worden. Kleine kans dat je daarvan last hebt, want bij de meeste servers is het bestandssysteem bijvoorbeeld met een RAID-configuratie redundant uitgevoerd.
Waar je eerder last van hebt, is onprofessioneel ge*** van sommige providers. Bijvoorbeeld wanneer een server kapot gaat en ze de back-up van 24 uur geleden terugzetten op een nieuwe zonder je even in te seinen...
Lol... vrijwel identieke reacties van jullie beiden wat betreft het terugzetten van een back-up.
Maar nu de cruciale vraag. Bij sommige cruciale bestanden die je requiret werkt niks meer als die bestanden niet bestaan. Als het echter gaat om een view/template dan zou de rest van de website nog gewoon kunnen werken. Echter, als ik niet zou controleren of een view bestaat... en er is inderdaad een back-up teruggeplaatst en het bestand ontbreekt, dan zal ik hier misschien nooit achter komen, omdat ik er niet op controleer en dus ook geen melding ontvang. Wellicht dan toch een goed idee om altijd te controleren of een bestand bestaat?
