eigen framework / beheersysteem

Door Ozzie PHP op 30-12-2010 16:10 gewijzigd op 06-01-2011 13:17

50.683 views

Hmmm, laat ik de vraag toch maar eens stellen. Ik wil graag een eigen framework / beheersysteem maken. De bedoeling is dat ik als het systeem klaar is heel makkelijk een website kan maken waar meteen al een standaard cms gedeelte in zit.

Ik ben al begonnen met een framework en ik maak daarbij gebruik van Zend Framework, maar nu vraag ik me het volgende af. Ik heb behoorlijk wat PHP kennis en ervaring inmiddels, maar ik heb hier geen opleiding voor gehad. Ik wil het mezelf dan ook altijd zo makkelijk mogelijk maken als ik aan het programmeren ben. Voorbeeld, als ik een databasequery wil uitvoeren dan wil ik niet een hele query in te hoeven typen, maar wil ik simpele functies kunnen gebruiken, bijvoorbeeld: $database->setTable('tabel') en $row = $database->select('naam') etc.

Ik gebruik Zend Framework met name omdat ik mooie routes kan maken, bijvoorbeeld www.mijnsite.nl/kantoorartikelen/nietmachine in plaats van www.mijnsite.nl/?category=4&product=2.

Ook vind ik het handig dat ik in Zend Framework een route makkelijk kan koppelen aan een controller en een actie. Daarnaast gebruik ik de MVC structuur (modules), de Zend_Registry functie om iets op te slaan en gebruik ik de caching functie voor het cachen van gegevens.

Ik gebruik Zend Framework dus voornamelijk voor:
- maken van mooie routes
- routes koppelen aan controller en actie
- MVC structuur (modules)
- Zend_Registry om variabelen op te slaan
- Caching

Voor de rest gebruik in Zend Framework eigenlijk niet. Ik weet dat er heeeel veel mogelijkheden in Zend Framework zitten, maar ik ben niet iemand die dat allemaal wil uitvogelen, en ik wil toch altijd graag mijn eigen code schrijven zodat ik precies weet wat de code doet en hoe deze in elkaar zit (zodat het voor mijzelf logisch is en makkelijk te gebruiken).

Nu vraag ik me 2 dingen af:
1) is het voor mij eigenlijk wel zinvol om Zend Framework te gebruiken aagezien ik er niet heel veel mogelijkheden van benut.
2) zijn de 5 functies waar ik gebruik van maak (makkelijk) ook zelf te maken of is dat heel erg ingewikkeld?

Wat raden jullie aan? Zend Framework blijven gebruiken ook al gebruik ik er maar weinig van? Of toch zelf mijn eigen functies maken en Zend Framework niet meer gebruiken? Ik stel deze vraag ook omdat Zend Framework zo'n 23mb aan serverruimte in beslag neemt.

Ozzie PHP

24-01-2011 21:48

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?

Pim -

24-01-2011 21:59

- 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?

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.

Ozzie PHP

24-01-2011 22:06

He... ik begrijp in 1x je uitleg :) Ik ga vooruit! Wat is en hoe werkt een Datamapper dan?

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')?

Pim -

24-01-2011 22:11

Als het goed is, let je DB laag op die types. Daar moet je je verder niet druk om maken.
Active Record:
<?php
$user = User::load($id) // Gaat statisch het netst
$user->save();
?>
Datamapper
<?php
$mapper = new UserMapper;
$user = $mapper->load($id);
$mapper->save($user);
?>

Ozzie PHP

24-01-2011 22:18

Die uitlegjes van jou worden steeds duidelijker Pim :)

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')?

Pim -

24-01-2011 22:25

Logisch gezien is het natuurlijk een getal, maar als het goed is, maakt het niet uit wat je gebruikt.

Ozzie PHP

24-01-2011 22:29

Oke, mijn vraag was ontstaan omdat iemand laatst zei dat wanneer je zoiets opslaat in een database je niet INT moet gebruiken, maar varchar. Zijn opmerking hierbij was dat je alleen iets als INT moet opslaan als je van plan bent om er mee te gaan rekenen. Deel jij die mening? En zo ja... zou je dan bij de functie aanroep het art.nr. ook niet als string moeten meegeven. Please help me out.

Pim -

24-01-2011 22:34

Nee. Als vuistregel kan je het best aannemen dat MySQL goed werkt ( ;) ) en dat je dus gewoon de types moet gebruiken waar ze voor bedoelt zijn. Getallen sla je dus op als INT.

Ozzie PHP

24-01-2011 22:40

Tja, dit maakt het verwarrend... zie de quote hieronder uit een ander topic:

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.

De een zegt dit, de ander zegt dat. Wat moet ik nu voor waarheid aannemen?

Pim -

24-01-2011 22:46

John heeft daar gelijk, maar er is een verschil tussen ids en andere gewone cijfers en (eeeeh) nummers uit de buitenwereld. Bij die nummers gaat niet om de waarde van het getal, maar om de tekens achter elkaar. Vaak is het dan ook belangrijk dat alle nullen behouden blijven. Ids zijn echter gewoon rangnummers in je DB, INTs dus.

Ook is de opslag van een INT (veel) efficiënter dan een varchar.

Reageren

Inloggen om te reageren