Ik ben me de laatste tijd een beetje aan het verdiepen in OOP.
Grotendeels begrijp ik wel hoe het zit met de denkwijze, en hoe je classes opbouwt e.d.
Maar wat ik nog niet echt begrijp is hoe je het gebruikt ik combinatie met een database.
Bijv. een class die een gebruiker toevoegt, met alle gegevens die bij de gebruiker horen.
Stel ik wil dan de volgende gegevens van een gebruiker in de database hebben.
Gebruikersnaam, email, wachtwoord, geboortedatum, enz.
Hoe doe ik dit?
Weet iemand hier een tutorial voor? Of misschien een simpel voorbeeldje?
Heb je je al ingelezen in de verschillende architectonische structuren die OOP biedt? In mijn applicaties ga ik altijd uit van een MVC (Model View Controller) architectuur, wat in ongeveer als volgt combineer met een (willekeurige) database:
- de database is gewoon een object. Voor simpliciteit ga ik even uit van een instantie van een PDO object.
- in de bootstrap van mijn applicatie wordt deze, aan de hand van een configuratiebestand, ingeladen.
- Enkel in klassen die tot de modellaag behoren, is er een mogelijkheid tot communicatie met de database.
- Concreter, in jouw geval zou er dus een model User of liever nog een UserMapper zijn (een mapper voert operaties uit op een, in dit geval, User object).
- Zoals gezegd heeft deze Mapper toegang tot de database. In de Mapper worden de queries opgesteld en resultaten (indien nodig) omgezet naar objecten.
- Bijna elke query zal in een eigen functie staan (zoals login($user, $pass)), welke vaak door de controller worden aangeroepen.
- That's it. Het is vrij globaal, aangezien je vraag dat ook was.
Door het MVC model te gebruiken, kan je een duidelijk gescheiden applicatie ontwikkelen, waar iedere klasse enkel toegang heeft tot datgene wat het verdiend (zo kan bv. alleen de controller HTTP headers verzenden).
"Waarom krijgt men altijd van dit soort reacties. "
Wel omdat je er om vraagt:
-> "Weet iemand hier een tutorial voor? Of misschien een simpel voorbeeldje?"
"Wanneer de vraag gelezen wordt. Dan wordt er met de vraag bedoeld in combinatie met mysql."
Houd het maar gewoon op database, dus dat kan zijn Oracle, PG, MSSQL Server, MySql, SLQ lite.
Voor een database class zal het in feite niet moeten uitmaken wat er verder aan database achter hangt.
Voor de rest is het een kwestie van OOP denken en doen, dan kom je vanzelf tot een bepaald resultaat wat redelijkerwijs door jouw begrepen wordt.
Je kan beter zelf het een en ander opzetten en de vraag dan stellen of je op de juiste weg bent.
class nieuws {
var $connectie;
function __construct() {
$this->connectie = $GLOBALS['connectie'];
$query1 = "
SELECT
titel
FROM
nieuws
ORDER BY
datum";
$result1 = mysql_query($query1, $this->connectie) or die ( mysql_error( ) );
while($row1 = mysql_fetch_row($result1)) {
// print ...
}
// of bijv.:
if($_SERVER['REQUEST_METHOD'] == 'POST') {
if($this->controleren()) {
$this->opslaan();
echo 'Wijzigingen zijn opgeslagen, u word automatisch door gestuurd bla bla';
} else {
echo 'Er is een fout ... ';
$this->formulier();
}
} else {
$this->formulier();
}
}
function opslaan() {
$query1 = "
UPDATE
nieuws
SET
datum = FROM_UNIXTIME(".$this->datum."),
titel = '".mysql_real_escape_string($this->titel)."',
html = '".mysql_real_escape_string($this->html)."',
bron = '".mysql_real_escape_string($this->bron)."',
aangepast = NOW()
WHERE
id = ".$this->itemnr;
mysql_query($query1, $this->connectie) or die ( mysql_error( ) );
}
}
new nieuws();
Zomaar paar stukjes uit class geknipt. Class staat eigenlijk ook in apart bestand die ik dan eerst include en dan aanroep. Net als andere classes, bijv van de bezoekers teller en dergelijke.
Uiteraard zit het wel allemaal wat omvangrijker in elkaar dan hier staat. Zo word bijv. gecontroleerd of verbinding maken met database ook echt lukt. Zo niet dan krijgt bezoeker een degelijke 'Servise tijdelijk niet beschikbaar' error pagina. Wil namelijk bij mij hoster(KPN!!!) wel eens voorkomen dat de database niet bereikbaar is.
Ik maak geen gebruik van een database class of zo iets omdat ik daar het nut niet zon van in zie bij mn eigen website. Voor grote website's waar meerdere mensen aan werken vast zeer nuttig, maar voor mn eigen site zie ik het nut niet.
Ik maak geen gebruik van een database class of zo iets omdat ik daar het nut niet zon van in zie bij mn eigen website. Voor grote website's waar meerdere mensen aan werken vast zeer nuttig, maar voor mn eigen site zie ik het nut niet.
Het voordeel van een aparte database klasse is niet zozeer dat het makkelijker administratief schaalbaar is, maar dat je de database beter kan monitoren.
Met één aanpassing in een configuratiebestand kan ik de database "debug/monitor" mode aanzetten, waardoor de database klasse de executietijden, resultaten en queries bijhoudt. Dit is natuurlijk handig voor het optimaliseren van je website.
Met één aanpassing in een configuratiebestand kan ik de database "debug/monitor" mode aanzetten, waardoor de database klasse de executietijden, resultaten en queries bijhoudt. Dit is natuurlijk handig voor het optimaliseren van je website.
Klinkt als veel regels code, veel omwegen in de code, die bij elke pagina geparst moeten worden(of die "debug/monitor" mode nou wel of niet aan staat) zonder dat ze een bijdrage leveren aan de pagina die aan de bezoeker voor geschoteld moet worden. Nogmaals: bij grote website's met grote databases, veel tabellen, enz. heeft het zeker nut, maar op mn eigen site zie ik het niet. De PHP scripts die ik in elkaar knutsel zijn gewoon nog met het verstand te volgen.
Omdat het een class is, is het juist niet veel regels code. Dat is de grap! In je config doe je dan iets als
<?php
if($development_environment)
$pdo = new Debug_PDO(...);
else
$pdo = new PDO(...);
?>
Als je dat ook nog combineert met autoloading (of je ervoor nog even een include statement zet) wordt je debug code niet eens geladen. En nergens anders hoeven er checks of je nu aan het debuggen bent of niet, zolang Debug_PDO maar exact dezelfde interface implementeert als PDO, wat niet zo moeilijk is als je Debug_PDO gewoon PDO laat extenden.
Omdat het een class is, is het juist niet veel regels code. Dat is de grap! In je config doe je dan iets als
<?php
if($development_environment)
$pdo = new Debug_PDO(...);
else
$pdo = new PDO(...);
?>
Ik heb voor composition over inheritance gekozen, dus dat ziet er ongeveer zo uit:
<?php
$db = new PDO/MySQLi(...);
if($development_environment) {
$db = new Debug($db);
}
?>
Wat betekend dat ik niet voor elke adapter (PDO, MySQLi) een aparte debug klasse hoef te maken. Zodra je de debug klasse inderdaad dezelfde interface laat implementeren als de "normale" adapters, heb je een prachtige wrapper klasse.
Als je verder de verschillende componenten cached (config, language files, routes e.d.) en lazyload implementeert (mijn database klasse maakt pas verbinding als de eerste query uitgevoerd moet worden, wat tijdwinst oplevert voor statische pagina's), kan je je applicatie supersnel en vooral efficiënt houden.
