pdo oop goed?

Ik begrijp niet helemaal waar je op doelt.

Het lijkt me sowieso niet nodig om de LIMIT 1 erin te steken, er is tenslotte maar 1 user met dit ID.

Als je het ID eventueel in een SESSION kunt opslaan moet je ook niet telkends het ID meegeven als variabele in de functies.

Waarom gebruik je trouwens in de eerste functie gewoon `users` en daarna `users.data`?

Mogelijk staat het niet op voorhand vast dat er resultaten zijn. Het fetchen voordat je dit hebt vastgesteld is misschien voorbarig.

Ook weet ik niet precies hoe je fouten afhandelt? Als dit met exceptions gebeurt moet je wellicht in de methoden van de User class, of waar je deze methoden in een andere class aanroept een try-catch blok gebruiken?

Daarnaast zou je volgens mij ook te allen tijde een try-catch blok moeten gebruiken wanneer je een connectie maakt via PDO want als deze om wat voor reden mislukt (zelfs als je database-credentials kloppen kan dit gebeuren) wordt een exception gethrowd. Een exception die niet gecatched wordt produceert een fatal error. En in die exception-boodschap (die ook in je fatal error wordt getoond) staan je database-credentials (don't ask lol).

Dan nog een observatie: je hebt nu twee methoden geschreven waarin je achtereenvolgens hetzelfde doet: prepare, execute, fetch. Wanneer je twee of meer keren een of meer van dezelfde handelingen uitvoert moet je je af gaan vragen of dit niet wat eenvoudiger kan. Een goed ontwerpprincipe is Don't Repeat Yourself (DRY). En tevens: prepare, execute, fetch over and over again: aint nobody got time for dat! Je zou kunnen overwegen om een kleine wrapper om PDO te schrijven zodat dit soort database-interacties minder regels code omvatten.

En dan nog het volgende: waarom gebruik je PDO en niet MySQLi? Als je toch enkel een MySQL-database gebruikt heb je niet per se PDO nodig, noch prepared statements. Laat de keuze voor de driver die je gebruikt (PDO(_MYSQL) of MySQLi) alsmede het gebruik van prepared statements (in PDO is dit een verplichting, in MySQLi is deze optioneel) een bewuste keuze zijn.

Dat is wat ik in de gauwigheid zo kan verzinnen.

Wat @wimmpie ook zegt: enerzijds gebruik je "users" (wat mij een tabel lijkt) en vervolgens "users.data". Heb je echt een (aparte?) database genaamd "users" en vervolgens een tabel genaamd "data"?

Als je veelvuldig verschillende gegevens van eenzelfde gebruiker opvraagt zou ik hier niet allemaal aparte queries voor schrijven, je kunt in één query prima alle (relevante) data ophalen van een gebruiker, zelfs als deze verspreid is over meerdere tabellen. En deze dan bijvoorbeeld in een hulp-array of User-object opslaan zodat je hier vervolgens aan kunt refereren.

Maar hoe je dit precies doet hangt ook af van:
- hoe deze data er uitziet (structuur)
- en wat je er mee wilt doen

Ik zie daar dingen als "bank" en "cash" voorbij vliegen. Wanneer je informatie opvraagt met als doel deze te veranderen dan is het belangrijk dat de informatie na opvragen (tijdelijk) read-only wordt tot (en na) het moment van het bijwerken van deze data. Als je dat niet doet dan kunnen er dingen fout lopen.

Stel bijvoorbeeld dat er 2 operaties bestaan in jouw applicatie die het volgende doen:
- geld storten
- geld opnemen

Stel dat jouw saldo 200 is.
Vervolgens worden er tegelijkertijd twee operaties uitgevoerd:
- 200 opnemen
- 50 storten

Wat is dan volgens jou het eindsaldo? 50 toch he?
Nou niet dus :). Althans niet als je je startsaldo eerst overhevelt naar een hulpvariabele en dan pas de bewerkingen uitvoert. Er kunnen dan -zonder speciale voorzieningen- meerdere eindantwoorden mogelijk zijn afhankelijk van de volgorde waarin de acties worden uitgevoerd. Het is mogelijk dat de einduitkomst een van de volgende waarden heeft:
50 (dit is wat we willen)
250 (dit is wat we niet willen)

Hoe komen we tot 250?
Noem 200 opnemen A
Noem 50 storten B

Dit is wat er achtereenvolgens zou kunnen gebeuren (A en B vinden "tegelijkertijd" plaats):
A vraagt saldo op: 200
B vraagt saldo op: 200
A neemt 200 op, eindsaldo volgens A: 0
B stort 50, eindsaldo volgens B: 250

Wanneer B voor de opname van A het saldo opvraagt en na het wegschrijven van het eindsaldo van A dit zelf doet heb je een niet-kloppend eindantwoord. Dit was mogelijk omdat er geen "lock" is op de waarde van het saldo. Normaal regel je dit met een voorziening in de database waarmee je gegevens tijdelijk kunt vergrendelen zodat slechts één proces deze data kan aanpassen. Beter bekend als een database-transactie. Net zoals een monetaire actie eigenlijk: alle stappen vormen tezamen één ondeelbare actie. Anders gebeuren er mogelijk rare dingen, zoals hierboven omschreven.

Daarom kan ik niet op voorhand zeggen hoe jij je data in PHP moet organiseren omdat ik niet weet hoe je hier in je database mee omgaat.

Nog wat extra toevoegingen.

Opzich is er niks verkeerd met de class zelf. Persoonlijk zou ik zelf wat dingen anders aanpakken. Om een voorbeeld te geven.

Mocht jij nu bijvoorbeeld de tabel field bank_number willen hebben moet jij een nieuwe functie aanmaken. Om dit te voorkomen kan je één functie maken die een gespecificeerd tabel field pakt. Het is al een tijdje geleden dat ik met PDO gewerkt hebt (meestal gebruik ik Eloquent ORM), maar zoiets zou ik doen:

<?php


class User
{
    /**
     * PDO Instance
     * 
     * @var
     */
    private $db;


    /**
     * User constructor.
     *
     * @param $pdo
     */
    function __construct($pdo)
    {
        $this->db = $pdo;
    }


    /**
     * Get the value of an field.
     *
     * @param $id
     * @param null $field
     * @return mixed|null
     */
    public function get($id, $field = null)
    {
        $data = $this->getAll($id);


        if (array_key_exists($field, $data)) {
            return $data[$field];
        }


        return null;
    }


    /**
     * Get from the users.data table.
     *
     * @param $id
     * @param null $field
     * @return null
     */
    public function getFromData($id, $field = null)
    {
        $data = $this->getAll($id, 'users.data');


        if (array_key_exists($field, $data)) {
            return $data[$field];
        }


        return null;
    }


    /**
     * Get all data.
     *
     * @param $id
     * @return mixed
     */
    public function getAll($id, $table = 'users')
    {
        $stmt = $this->db->prepare("SELECT `username` FROM `{$table}` WHERE id=:ID LIMIT 1");
        $stmt->execute(array(':ID'=>$id));


        return $stmt->fetch(PDO::FETCH_ASSOC);
    }
}

En dan zou je bijvoorbeeld met de volgende code de name opvragen:

<?php


$user = new User(null); // null needs to be the PDO Instance
$userName = $user->get(1, 'username');

Overgins is het misschien goed om te kijken naar namespacing en autoloading. Hier kan je bijvoorbeeld composer voor gebruiken of zoiets.

Hoe los je hiermee het eerder aangekaarte (potentiële) probleem op?

Het kiezen van een technische oplossing / implementatie voordat je weet wat iemand probeert te bereiken lijkt mij niet verstandig.

"Kies een stuk gereedschap"
- "Ok" (pakt schroevendraaier)
"Mooi, gaan we nu de heg snoeien"

Citaat van MBCompany

k ben bezig met een user class maar denk dat k het fout aanpak

hoe kan het goed doen? krijg geen errors ofzo maar denk dat k et fout aanpak

Zover ik begrijp staat hier letterlijk dat er geen probleem is, maar dat MBCompany twijfelt aan zijn aanpak. Daarop geef ik mijn mening hoe ik het zou aanpakken.

Maar als jij niet weet wat zijn eindbestemming is, hoe kun je dan zeggen hoe jij zijn reis (waar naartoe?) zou moeten plannen?

Metafoor: jij stopt jouw lievelingskleding in zijn koffer, maar die is mogelijk helemaal niet geschikt voor het klimaat van het land van bestemming.

De eerste vraag aan de topicstarter zou eigenlijk moeten zijn: "wat probeer je bereiken" of "wat wil je (kunnen) doen"?

Verder zou je inderdaad praktische tips kunnen geven over het gebruik van PDO, maar los van een specifieke oplossingsrichting omdat je simpelweg niet weet of de gekozen techniek dan wel geschikt is. De topicstarter verschaft op dit gebied in wezen onvoldoende informatie. Het is niet onze plaats om daar dan vervolgens aannames over te doen.

Iets met een gegeven paard en niet in de bek kijken.

Mja, iets met iemand met een kluitje het riet insturen.

Of iets met het paard achter de wagen spannen.

Het is wel erg makkelijk om zo te reageren.

Je advies is gebaseerd op aanames / eigen ervaring. Stap 1 lijkt mij het toetsen van die aannames, om er verzekerd van te zijn dat je het juiste gereedschap gebruikt om de klus te klaren.

Zoals @D.Oomens al eerder vermeld; je kan proberen een ORM te overwegen (Eloquent ORM).

Hiermee heb je geen zorgen m.b.t. het aanroepen van de database en het beheren hiervan en hoef je je alleen te focussen op je datamodellen. De ORM regelt de connectie en de queries...

Misschien kan je zelfs overwegen gewoon een bekend framework te gebruiken want zelf code schrijven kost veel tijd voor vaak hetzelfde doel...

<?php
/**
* Get the value of an field.
*
* @param $id
* @param null $field
* @return mixed|null
*/
public function get($id, $field = null)
{
    $data = $this->getAll($id);
    if (array_key_exists($field, $data)) {
        return $data[$field];
    }
    return null;
}
?>

Euh, dit retourneert niets als je enkel een id invult? En als het echt de bedoeling is dat je enkel een kolom(waarde) retourneert dan zou ik de methode getField oid noemen en $field verplicht maken.

@MBCompany omdat je nog enigzins zoekende lijkt en nog niet al te lang bezig met met OOP zou ik gewoon simpel beginnen en niet direct allerlei abstractielagen in je code aanbrengen. Dit is misschien ook helemaal niet nodig voor hetgeen je probeert te bereiken.

Wat mij weer terug brengt bij mijn eerdere vraag: wat wil je met deze class kunnen doen? Zoals eerder aangegeven: je kunt met één of enkele queries bij creatie van een User object alle data van een user wel binnenharken, je hoeft hier niet per kolom een methode voor te gebruiken.

Wel moet je je bewust zijn van het feit dat je daarmee in principe een kopie trekt van de overeenkomstige gegevens in de database, en deze gegevens kunnen mogelijk in de "tussentijd" veranderen. In je User object zitten dan dus potentieel verouderde gegevens. Vooral als je met "geld" tussen users gaat schuiven (is dit een criminals spel ofzo?) moet je goed op gaan letten. Wat je hebt geschreven is niet per definitie goed of fout, maar naar aanleiding van wat ik voorbij zie komen zie ik wel wat verkeersborden opdoemen.

Citaat van M.Beers

De ORM regelt de connectie en de queries...

Maar die implementeer je toch voor een groot deel zelf? Dan moet je toch ook (zelf?) rekening houden met locking van tabellen/kolommen? Los daarvan lijkt dit mij niet iets waar een startende OOP programmeur headfirst in moet duiken. Verder is een ORM niet noodzakelijk. Dus waarom zou je een applicatie standaard uitrusten met zo'n abstractielaag? Dit alles kan ook gewoon in native (OOP) PHP. Dat lijkt mij in dit geval een beter startpunt.

Citaat van FangorN

Maar die implementeer je toch voor een groot deel zelf?

In het geval van Eloquent (laravel) hoef je slechts de "database" package op te halen en de gegevens is een Capsule object te plaatsen om alles te configureren ... geen rocket science de rest doet Eloquent voor je...

<?php
$this->capsule = new Capsule;
        $this->capsule->addConnection([
          'driver'    => 'mysql',
          'host'      => DB_HOST,
          'port'      => DB_PORT,
          'database'  => DB_NAME,
          'username'  => DB_USER,
          'password'  => DB_PASSWORD,
          'charset'   => 'utf8',
          'collation' => 'utf8_unicode_ci',
        ]);


        $this->capsule->bootEloquent();
        $this->capsule->setAsGlobal();
        $this->schema = $this->capsule->schema();
?>

Ok, installeer Laravel (ook nodig?) en Eloquent en alles gaat vanzelf! Je hoeft niet eens meer na te denken over wat je doet. Handig.

De Database package van illuminate kan gebruikt worden zonder Laravel. Wel is het handig om hier Composer voor te gerbuiken.

Iedereen die OOP wil leren programmeren en niet te veel wil omkijken naar veilig omgaan met SQL, PDO, etc, etc zal ik aanraden om deze package te gebruiken. Aan deze (korte) uitleg heeft @MBCompany misschien wat. Natuurlijk kan het geen kwaad om zelf is te duiken in de wereld van PDO en dergelijken.

Kleine off topic:
Als je de basis van PHP onder die knie heb zal ik je aanraden om eens te gaan kijken naar een PHP Framework. Laravel heeft mijn persoonlijke voorkeur, maar buiten mijn voorkeur domineert Laravel de markt op het gebied van PHP MVC Frameworks. Ik ben er twee jaar geleden mee begonnen en doe nooit een project zonder Laravel. Toen ik begon wist ik niet eens wat composer, autoloading, models, views en controllers waren. Gewoon een kwestie van vallen en opstaan. Natuurlijk kan je ook een ander Framework gebruiken.

Een framework bespaart je enorm veel tijd, de klus is veel sneller geklaard. Dat is een FEIT.

Als ik met goed herinner heeft er iemand ooit een beginners blog voor gemaakt op ICTscripters. Misschien dat ik die ooit opnieuw maak of verder uitwerk. Als er genoeg vraag naar is.

Citaat van D.Oomens

Iedereen die OOP wil leren programmeren en niet te veel wil omkijken naar veilig omgaan met SQL, PDO, etc, etc zal ik aanraden om deze package te gebruiken

Iemand die niet teveel wil omkijken naar veilig omgaan met X kan beter een ander vakgebied kiezen. Elke serieuze ontwikkelaar zou zich bewust moeten zijn van gevaren, risico's en pitfalls. Hoe vaak het voorkomt dat iemand PDO gebruikt omdat 'ie gehoord heeft dat dit veilig zou zijn, en vervolgens querystrings in elkaar gaat metselen waarin niet ge-escapete userdata zit... Indien je de spelregels van een techniek niet kent noch toepast, waarom gebruik je dan die techniek? Dit heet in de volksmond ook wel "prutsen".

Citaat van D.Oomens

Een framework bespaart je enorm veel tijd, de klus is veel sneller geklaard. Dat is een FEIT.

Hangt er vanaf wat je uitganspunt en je uitgangspositie is.

Indien je net bent begonnen met de beginselen van OOP dan denk ik niet dat het er tussenknallen van allerlei technieken en abstractielagen echt bevorderlijk werkt qua ontwikkeling. Je zult je (enigszins) moeten bekwamen in de tools waarmee je werkt.

Daarnaast is het de vraag of je al deze flexibiliteit (en ook abstractie en complexiteit) nodig hebt. Dit hangt af van de te klaren klus. Mijn uitgangspunt is use the best tool for the job. Zolang je niet weet wat de klus omvat is het nogal voorbarig om alvast je gereedschap te kiezen. Ook zou je zo'n keuze moeten kunnen onderbouwen en niet simpelweg methode X of technologie Y kiezen toevallig omdat jij die fijn vindt werken. Mogelijk kunnen dingen veel simpeler opgelost worden.

Plus als je iets verkeerd toepast is het eindresultaat nog steeds... onbruikbaar (zie codefragment). Uiteindelijk zijn het dan alleen maar dure woorden met 0,0 toegevoegde waarde. Maar goed, doe je ding.

Moet je echt alles afkraken @FangorN? Misschien dit niet:

Voor TS: Er is niks verkeerd met nieuwe technieken leren. Misschien kan je is naar Laravel kijken.

Waarom is het gebruik van een framework voor niet elke job mogelijk? De best tool voor een job kan altijd een framework zijn. Des al niet te min zijn frameworks juist ontwikkeld om het leven van een programmeur op diverse gebieden juist makkelijker te maken dan wanneer je iets van scratch bouwt. Denk aan routering, SQL, forms en ga zo maar door.

Waarom zou je voor een kleine website geen framework gebruiken en voor een grote wel? Ik gebruik zelf Symfony voor alles, ook voor kleine websites.. waarom? Puur omdat ik mezelf heb leren programmeren met symfony en omdat ook met kleine websites zoveel zaken al van te voren klaar staan geprogrammeerd.

Wanneer ik dit zelf moet programmeren, zal het altijd van mindere kwaliteit zijn dan een door ontwikkeld framework. Een framework foutief gebruiken? Zover ik weet is een framework een basis waarop je kan door bouwen, ja het is handig om de hooks etc te gebruiken die zijn aangeboden, maar als je rechtstreeks op de core kan inprikken (Code Igniter met Get_Instance() bijvoorbeeld) en it gets the job done, waarom dan niet?

Mee eens dat een programmeur moet weten waar hij mee bezig en kennis moet hebben van OO en de daarbij behorende technieken van escapen, sql etc, maar een programmeur in websites vergeet daarnaast ook vaak het aspect SQL goed te gebruiken ondanks dat men al 10 jaar in het vak zit, een view in SQL wat is dat? Een stored procedure? toch nergens voor nodig?

Er zijn zoveel manieren om een website op te bouwen niet OOP, procedureel en alles heeft zijn voor en nadelen. Omdat toevallig één persoon niet gebruikt maakt van de techniek zoals jij dat doet wilt niet per definitie zeggen dat het fout is...

@FangorN omdat toevallig niet iedereen van scratch alles afbouwt elke keer opnieuw of zijn eigen framework ontwikkelt wilt niet zeggen dat het fout is, i'll be damned zoek maar op het internet naar vactures voor specifieke frameworks (Zend, Laravel, CI) zijn allemaal vacatures voor, dus in de "proffesionele" wereld gebruiken ze het ook gewoon, dan hoeven ze dus ook niks meer te doen? Ik noem dat niet lui ik noem daat slim programmeren.

Er is ook nog iets als kosten & baten verhaal...