dicht timmeren?
Pagina: « vorige 1 2 3 4 5 volgende »
Je weet wie het zegt he ;-) Beter dan dat iemand het zegt met zun volle verstand.
Gewijzigd op 01/03/2012 10:15:59 door Niels K
$rows = $database->select('veld')->from('tabel');
Nu wil ik per pdo driver een class maken (ik noem 'm even "class X") die gebruik maakt van een aantal aparte "basis classes" voor iedere functie (select, insert, update, delete).
Oké, so far so good...
Nu wil ik in "class X" een magische __call functie gebruiken die op basis van de aangeroepen functie een van de "basis classes" aanroept.
$rows = $database->select()->... roept de basis class "PDO_Select" aan
$database->delete{}->... roept de basis class "PDO_Delete" aan
enz.
Nu mijn vraag:
Als ik een niet bestaande functie aanroep:
$database->bestaatniet()
Dan wordt via mijn autoload functie een niet bestaande class aangeroepen, namelijk "PDO_Bestaatniet". Mijn autoload functie gooit dan een exception die keurig meldt dat de class "PDO_Bestaatniet" niet bestaat.
Stel nu dat je als programmeur een typefoutje maakt:
$database->duhliet()->...
Dan krijg je een melding dat de class "PDO_Duhliet" niet bestaat. Echter, het zou gebruikersvriendelijker zijn om een "relevante" foutmelding te tonen, bijvoorbeeld:
De door u aangeroepen database actie "duhliet" bestaat niet.
Nu kan ik dit wél voor elkaar krijgen door eerst te controleren via file_exist of de class (het bestand) bestaat.
Dit houdt alleen wel in dat bij iedere database actie die ik doe een file_exist controle moet worden gedaan om te controleren of het een geldige functie betreft.
De afweging is nu dus:
1) Als de functie niet bestaat wordt een foutmelding getoond dat de class niet bestaat. Deze oplossing is niet zo heel gebruiksvriendelijk omdat de foutmelding niet echt heel duidelijk is.
2) Als de functie niet bestaat, wordt er keurig een foutmelding getoond die meldt dat de betreffende database functie niet bestaat. Helemaal top, super gebruiksvriendelijk! ...alleen bij iedere database actie die wordt uitgevoerd moet wel even een file_exist worden uitgevoerd.
Welke van deze 2 opties heeft jullie vooorkeur?
Ik denk dat je heel even de mist in gaat met je denkwijze. Waarom voor elke actie een nieuwe class? Ik weet niet hoeveel methode PDO heeft maar zal toch wel richting de 50 gaan.. Is dat geen overkill? ;-)
Probeer eens gebruik te maken van het Adapter pattern?
Voorbeeld: (heel summier)
Code (php)
1
2
3
4
5
2
3
4
5
<?php
abstract Db_Adapter_Abstract {}
?>
abstract Db_Adapter_Abstract {}
?>
Bovenstaande is de normale 'abstract' class van de database handler. Je kan dan verschillende Adapters hebben.
- PDO
- Mysqli
- Oracle
- Db2
- Sqlsrv
Zijn er vast nog wel meer te vinden, maar het gaat even om het idee. Stel we willen als adapter class Mysqli:
En wat als we nu PDO willen doen? Voor PDO heb je toch ook verschillende Adapters? Jep, dat klopt. Geen enkel probleem. We maken weer een abstracte class
Als we dan een PDO Mysql adapter willen gebruiken doe je dat als volgt:
Snap je de werking van mijn opzet? Snap je wat een abstracte class doet en kan? Als je deze structuur gebruikt houd je, je nog netjes aan het Adapter pattern ook. Tenminste dat denk ik ;-)
De aanvulling van de methodes moet je even zelf verzinnen. Is gelijk een mooie oefening om het een beetje onder de knie te krijgen.
Het gaat mij namelijk om de denkwijze die jij op dit moment hebt. Het is ansich begrijpelijk dat je zo denkt, maar dat betekend niet dat het ook daadwerkelijk allemaal klopt.
Wanneer je dit helemaal snapt en (goed) geïmplementeerd hebt kunnen we eens gaan kijken naar het verder bouwen van je ORM.
Succes ;-)
Mijn bedoeling was om te doen wat Wouter zegt. Dus een aparte (pdo) class voor select, update, insert en delete. Uitsluitend voor die acties wil ik een aparte class maken. Dat zijn er dus 4. Per class krijg je dan weer specifieke functies die bij een select/delete/update/insert query horen. Is dat niet goed dan?
Toevoeging op 03/03/2012 15:28:39:
Oh ja, voordeel als je die 4 losse classes gebruikt... ik kan alleen de functies aanspreken die bij een select/update/insert/delete query horen omdat alleen deie functies in de class aanwezig zijn.
Ik kan dus niet per ongeluk zoiets doen als
$rows = $database->select()->from()->delete()->where();
Aangezien de functie delete() in de select class niet bestaat kan ik deze dus ook nooit aanroepen. Dat lijkt me toch ook wel een voordeel van het gebruik van losse classes.
Het lijkt me ook een stuk beter OO, omdat je zo de taken van read, create, update en delete verdeelt over verschillende klasse.
Gewijzigd op 03/03/2012 16:47:05 door Wouter J
Stel dat je een functie setString($string) hebt, die alleen door programmeurs wordt gebruikt. Moet je er dan vanuit gaan dat de programmeur zo slim is dat ie inderdaad een string invoert, of moet je de invoer toch typecasten naar een string?
Dus:
Is dit een goede gewoonte of is het overkill?
Of moet je het nog verder doortrekken:
Code (php)
1
2
2
<?php
function setString(string $string)
function setString(string $string)
$string = trim($string." ");
Code (php)
1
2
3
2
3
<?php
$str = ''.$myStr;
?>
$str = ''.$myStr;
?>
Dit is geen typecasten, maar type juggling.
Gewijzigd op 06/03/2012 18:13:54 door Wouter J
Code (php)
1
2
3
2
3
<?php
$string = (string) $string;
?>
$string = (string) $string;
?>
Excuses voor de laatste reactie, dit topic was me heel even ontschoten.
Wouter, naar mijn mening heb jij het bij het rechte eind. Je zou voor de grap eens moeten kijken naar Zend_Db en naar Zend_Db_Table. Dat vind ik persoonlijk een geweldige oplossing.
@Ozzie,
Ik cast nooit wat ;-) Of iig bijna nooit.
(ik deed het voorheen ook niet...)
Voorbeeld:
Ik kan via een select functie gegevens opvragen uit de database.
$row = $database->select('veld1', 'veld2')->from(...)->where(...)
Wat ik nu doe, is controleren of ieder veld in de select functie een string is. Zo niet dan gooi ik een Exception. Datzelfde doe ik bijvoorbeeld ook voor de from. Is de opgegeven tabel naam een string? Nee? Dan gooi ik een Exception.
Ik zou ook de veldnamen in de select functie kunnen typecasten naar strings, maar als iemand dan true (een boolean) als veldnaam zou invoeren, dan zou dit worden omgezet naar een "1" en dan krijg je wellicht onverwachte resultaten terug. Vandaar dat ik dus controleer of de veldnaam een string is.
Ander voorbeeld:
Een functie om een bericht op het scherm te tonen. De parameter $exit geeft aan of het script na het tonen van het bericht moet stoppen (die). Ik controleer in de functie of de parameter $exit wel een boolean is. Zo niet, dan gooi ik een Exception.
Wat vinden jullie? Hoe ver moet ik gaan? Want om nu in iedere functie te gaan controleren of de verwachte invoer een string is... tja, ik weet het niet :-s
Graag advies!
Gewijzigd op 14/03/2012 08:51:21 door Ozzie PHP
Pagina: « vorige 1 2 3 4 5 volgende »