eigen framework / beheersysteem
Pagina: « vorige 1 2 3 ... 8 9 10 11 12 volgende »
Mar cel op 24/01/2011 21:31:42:
...er wordt door de gebruikers met de moeilijkste termen gegooid. Zou je niet eerst even met de basis beginnen van het programmeren in OO, voordat je begint aan geavanceerde MVC-frameworken?
Correct, ik ga beginnen met de simpele variant, die van phppro... maar heb een project tussendoor dus gaat niet zo snel als ik zou willen. Maar in de tussentijd kabbelt de discussie lekker voort en heb ik straks hopelijk een hoop input. Weet je antwoord op mijn vraag over de fietsen?
Quote:
- van alle 50 fietsen een object maken? (waarin behalve de naam, prijs en plaatje ook een omschrijving en specificaties zijn opgenomen. Met andere woorden je laadt dus veel te veel informatie in)
- van alle 50 fietsen een object maken, maar niet alle gegevens inladen?
- gewoon de relevante gegevens uit de database ophalen en in een array zetten en dus niet met objecten werken?
- van alle 50 fietsen een object maken, maar niet alle gegevens inladen?
- gewoon de relevante gegevens uit de database ophalen en in een array zetten en dus niet met objecten werken?
Tsja... Ik vind persoonlijk het omgaan met 'Domain Objects' in een database een van de lastigste dingen om mooi/goed te doen.
Optie 1 sowieso niet. Optie 3 kan, maar is niet OOP. Optie 2 is het mooist.
De makkelijkste optie hiervoor is het Active Record. Het object houdt dan zelf de relatie met de DB in stand. Dit heeft als nadeel dat je lastiger kan (Unit) testen en dat dat object dan 2 taken heeft: het zijn van een fiets en het zijn van het opslagmechanisme voor die fiets.
Mooier en ook makkelijk is de Datamapper. Een mapper regelt dan de opslag, de fiets zelf niet.
Met Active record bedoel je zoiets als:
$fiets->load('23231') waarbij 23231 het artikelnummer is?
ps... laatst zie iemand hier dat wanneer je een waarde in een database opslaat als INT, je deze waarde alleen als INT moet opslaan op het moment dat je er mee wilt gaan rekenen. Geldt dat voor een artikelnummer eigenlijk ook? Het is een getal, maar je gaat er niet mee rekenen. Wordt het dan $fiets->load(23231) of $fiets->load('23231')?
Active Record:
Code (php)
1
2
3
4
2
3
4
<?php
$user = User::load($id) // Gaat statisch het netst
$user->save();
?>
$user = User::load($id) // Gaat statisch het netst
$user->save();
?>
Datamapper
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$mapper = new UserMapper;
$user = $mapper->load($id);
$mapper->save($user);
?>
$mapper = new UserMapper;
$user = $mapper->load($id);
$mapper->save($user);
?>
Ik denk dat ik dan toch de voorkeur geef aan de Active Record methode. Dat voelt voor mij natuurlijker aan dan zo'n datamapper.
"Als het goed is, let je DB laag op die types. Daar moet je je verder niet druk om maken."
Maar gewoon vanuit de logica gezien... moet je een artikelnummer behandelden als een int of een string? Hoe moet ik 'm meegeven aan de load functie: zo $fiets->load(23231) of zo $fiets->load('23231')?
John D op 03/01/2011 15:24:33:
Ga je rekenen met telefoonnummers ? Telefoonnummer A + 10x Telefoonummer B ??
Niet rekenen met de data dan geen rekenkundige tabel attributen gebruiken zoals INT, FLOAT etc. Voor huisnummers, telefoonnummers, burgerservicenummers, rijbewijsnummers, paspoortnummers, BTW nummers, KvK nummers altijd VARCHAR gebruiken.
Niet rekenen met de data dan geen rekenkundige tabel attributen gebruiken zoals INT, FLOAT etc. Voor huisnummers, telefoonnummers, burgerservicenummers, rijbewijsnummers, paspoortnummers, BTW nummers, KvK nummers altijd VARCHAR gebruiken.
De een zegt dit, de ander zegt dat. Wat moet ik nu voor waarheid aannemen?
Ook is de opslag van een INT (veel) efficiënter dan een varchar.
Dat is toch ook gewoon een rits cijfertjes achter elkaar?
- id's => INT
- aantallen => INT
- identificatiecodes => varchar
Gewijzigd op 24/01/2011 23:17:28 door Ozzie PHP
[/tip]
Pagina: « vorige 1 2 3 ... 8 9 10 11 12 volgende »