Door
Ozzie PHP
op 25-02-2014 00:42
gewijzigd op 25-02-2014 01:05
4.489 views
Ola,
Korte vraag. Ik zit me af te vragen... Stel ik heb 2 classes waarin ik de data van een request wil opslaan. In de ene class wil ik client data opslaan en in de andere server data. Voor welke mappenstructuur zouden jullie dan kiezen? A, B of C? (Ik snap dat er nog meer mogelijkheden zijn, maar ik zou graag weten welke van deze 3 jullie voorkeur heeft en waarom.)
A)
/request/
clientdata.php
serverdata.php
Of voor deze manier:
B)
/request/
data/
clientdata.php
serverdata.php
Of...
C)
/request/
data/
client/
data.php
server/
data.php
Het gaat me er vooral om wanneer je überhaupt over moet gaan tot het aanmaken van nieuwe directories. Je kunt zeggen dat beide classes onderdeel van het request zijn, en ze dus gewoon in de request map zetten (A). Je kunt ook zeggen dat het fenomeen "data" weliswaar tot het request behoort, maar een apart onderdeel daarvan is (B). En je kunt vervolgens binnen die data ook weer aparte mappen maken omdat het om verschillende typen, client en server, data gaat (C). Ben benieuwd naar jullie reacties en vooral hoe jullie daar mee omgaan en waar jullie je keuzes op baseren.
Ward, kun je nog iets verder uitleggen wat je bedoelt met "Uiteindelijk verwerk je altijd data". Zelf zat ik zo te denken, "data" is een onderdeel van het request, dus ik zet alles wat met data te maken heeft in een aparte map. Ik stel deze vraag omdat ik mezelf in een situatie aan het manoeuvreren ben, waarbij ik ieder afzonderlijk onderdeeltje in een aparte map aan het zetten ben. Dit is ontstaan toen ik met exceptions ben gaan werken. Ik vind het prettig om met eigen exceptions te werken ipv de spl library exceptions. Iedere class die dan een exception kan gooien, die wil ik een eigen exception class geven, zodat ik specifiek per class kan kijken of er een exception wordt gegooid. Velen zullen dit wellicht niet prettig vinden, maar ik vind het een fijne manier van werken.
Stel je hebt een mapje met autoloaders, dan wil ik dus iedere autoloader een eigen map geven, dus zeg maar dit idee:
/autoloader/
autoloader.php // dit is de algemene systeem-autoloader
psr/
autoloader.php // een psr autoloader
Stel dat de psr autoloader een exception zou moeten gooien, dan gaat dat nu heel makkelijk:
/autoloader/
autoloader.php // dit is de algemene systeem-autoloader
psr/
autoloader.php // een psr autoloader
exception.php // een psr autoloader exception
Stel echter dat ik alles in één map zou zetten, dan zou je zoiets krijge:
/autoloader/
autoloader.php // dit is de algemene systeem-autoloader
psrautoloader.php // een psr autoloader
psrautoloaderexception.php // een psr autoloader exception
Om dit soort lange bestandsnamen te voorkomen leek het me dus een goed idee om met mappen te werken. Maar het probleem daarvan is weer dat je heel veel mappen krijgt, waar vaak maar één bestand in staat (omdat niet zo heel veel classes een exception hoeven te kunnen gooien).
Heb je misschien nog wat advies, of een soort algemene stelregels hoe ik hier het beste mee om kan gaan?
Wouter J op 25/02/2014 10:31:12
Behalve dat ik zou aanraden om altijd een vendor naam in je namespace op de eerste plek te zetten.
Helemaal gelijk in. Voor het gemak heb ik die even weggelaten.
Je schuift voortdurend "data" heen en weer. Een request bevat data, een response bevat data en zelfs elke property is een vorm van data. Data is in dit verband een overbodige toevoeging. En meer praktisch vind ik het overzichtelijker als je de term data reserveert voor databases en andere vormen van data-opslag.
Ik zou één Request-hoofdcontainer gebruiken en die uitgebreider splitsen. Jouw tweedeling client/server is te veel ingegeven door netwerktechnologie. Bij het programmeren heb je eerder afzonderlijke componenten nodig voor bijvoorbeeld de POST bij formulieren, een cookie en een sessie. En die hebben meestal zowel client- als serverdata. Die tweedeling werkt daarom niet goed, denk ik: er is zowel te weinig als te veel overlapping met andere objecten, waardoor verantwoordelijkheden verkeerd verdeeld worden.
PSR heeft een eigen \Psr namespace. Daar hoort dus ook een PSR-autoloader in.
Thanks, dit gaat meer over welke onderdelen bij elkaar horen. Ik ben juist benieuw hoe je zo'n "onderdeel" of map op de beste manier kunt inrichten.
>> En meer praktisch vind ik het overzichtelijker als je de term data reserveert voor databases en andere vormen van data-opslag.
Ik snap wat je bedoelt, maar als ik het gewoon "client" zou noemen, dan lijkt het alsof het om de persoon "client" gaat, en niet om de data.
>> Bij het programmeren heb je eerder afzonderlijke componenten nodig voor bijvoorbeeld de POST bij formulieren, een cookie en een sessie.
Ben ik wel met je eens, maar is het nodig om voor cookie, files, get, post aparte classes te maken? Volgens mij zien die classes er toch allemaal hetzelfde uit? Ze moeten een get() en has() method hebben en dan ben je er al. In het kader van DRY (don't repeat yourself) is het toch niet goed om daar dan 4 classes voor te maken?
>> maar is het nodig om voor cookie, files, get, post aparte classes te maken? Volgens mij zien die classes er toch allemaal hetzelfde uit? Ze moeten een get() en has() method hebben en dan ben je er al. In het kader van DRY (don't repeat yourself) is het toch niet goed om daar dan 4 classes voor te maken?
Dan delen ze een get() en has() in een gemeenschappelijke RequestInterface of AbstractRequest, maar er is nog steeds een groot verschil tussen een $_POST en een $_COOKIE, zelfs al komen ze allemaal tegelijk binnen via één request. Met de methoden om iets uit $_POST te halen kun je geen fatsoenlijk cookie zetten.
Met de methoden om iets uit $_POST te halen kun je geen fatsoenlijk cookie zetten. Klopt, maar de vraag is dan of je een cookie moet setten in de request of in de response. Ik zou zeggen dat laatste.
Maar goed, eigenlijk ging mijn vraag daar dus niet echt over. Ik wil graag weten hoe ik het beste mijn mappenstructuur kan inregelen. Stel dat ik wel alles een eigen map geef, en dus voor een optie als deze zou kiezen:
/request/
data/
client/
data.php
server/
data.php
Zitten daar dan nadelen aan? Wordt mijn systeem daar bijvoorbeeld trager door?
Het nadeel is vooral dat je dan geen overzichtelijke namespace hebt.
Als je het extreem snel wilt maken, laadt je PHP-opcode via één bestand per applicatie uit een RAM-cache. Maar hoe je de boel later compileert, staat los van hoe je het geheel eerst bouwt.
>> Het nadeel is vooral dat je dan geen overzichtelijke namespace hebt.
Sorry dat ik even een boel vraag, maar wat bedoel je hier meer? Voor de client data zou de namespace dan worden:
Vendor\Request\Data\Client
Wat vind je daar niet overzichtelijk aan?
Nogmaals, ik weet dus niet of mijn idee met mappen goed is, of beter kan. Dus vandaar dit topic. Ik hoop vooral op nieuwe ideeën te komen. Stel dat we bijv. ClientData.php wel in de request map zetten en we willen ook een bijbehorende exception, dan krijg je wel een hele lange bestandsnaam, terwijl ik juist dacht dat het idee van de namespaces (o.a.) was om niet van die lange bestandsnamen te krijgen:
/request/
ClientDataException.php
Ik wil niet zeggen dat het niet kan, maar ik vraag me dus af of het een "beter" is dan het ander, en wanneer je nu wel of niet mappen moet gebruiken. Jouw eerdere opmerking over "PSR heeft een eigen \Psr namespace. Daar hoort dus ook een PSR-autoloader in." begrijp ik overigens niet. Het is gewoon een type autoloader die overweg kan met psr namespaces. Oh wacht, je bedoelt dat jij die autoloader niet in de "autoloader" map zou zetten, maar in een "psr" map?
