OOP icm MVC, hoe doen jullie het?
ik wil graag een eigen php framework schrijven, vooral om OOP en MVC te leren en een beetje voor de lol.
nu wilde ik jullie vragen hoe jullie dit aanpakken.
ik wil in het speciaal weten waar jullie allemaal een class voor hebben, en hoe jullie map structuur eruit ziet. hoe handel je bijvoorbeeld een ajax request af? gebruik je één index bestand wat alle functies uitvoert, of gebruik je voor ieder deel van de site een andere (nieuw, gastenboek, admin).
ik hoe dus geen hele lappen voorbeeld code, maar vooral een beetje extra uitleg over het hoe en wat van het schrijven van een framework. en informatie over hoe jullie het aanpakken.
Ivar
PS links naar must-read site's zijn ook welkom (eventueel ook boeken, maar ik ben meer een voorstander van het {gratis->ik ben Hollander :P } internet)
@PHP Newbie: ik zal even naar zend kijken, ik neem aan dat je het als voorbeeld bedoelde om te zien hoe zij het aanpakken?
@Boaz: dat is een erg handige pagina, daar kan ik wat mee! (ik zal ook even verder kijken in die wiki volgens mij staat er nog wel meer interessants)
Boaz schreef op 16.01.2009 19:43:
Het design pattern Front Controller is wat mij betreft een 'must read'. Op phpfreakz staat er een toegankelijk artikel over: http://wiki.phpfreakz.nl/FrontController
Daar wordt het inderdaad goed uitgelegd.
Meestal heb je een router/request object. Deze vertelt de frontcontroller wat de Controller en Action zijn.
De frontController include dan het bestand waar deze controller class instaat.
Eventueel wordt er dan eerst een init() method aangeroepen, dan de action, en eventueel wordt daarna met behulp van het view object alles weergegeven.
Nu ontbreekt het Model nog. Dit is een abstractie laag van de data. Bijvoorbeeld van een database tabel, met de methods fetchAll(), fetchRow($id), insert($data), update(), delete().
Om nog een stapje verder te gaan met je models, zou je voor elke rij een eigen object kunnen maken, en voor meerdere rijen (die je bijvoorbeeld met fetchAll) returnt een rowGroup object kunnen maken. Dat rowGroup object maak je dan 'iteratible' door de Iterator interface te gebruiken...
Even samengevat:
Controller handelt (icm de FrontController) alles af, die 'weet' wat er moet gebeuren, haalt de data op via models en stuurt die (met eventuele verwerkingen) door naar het view object.
Model zorgt dus voor je data abstractie. Zo hoef je in je controllers dus geen SQL queries te gaan maken, maar kan je dat eventueel in je models doen. Je model extend bijvoorbeeld Framework_Db_Table
View zorgt voor de weergave. Dit kan bijvoorbeeld een template parser zijn. Via de controller stop je er allemaal variabelen en data in, en via de render() method zet je dan alles op het scherm. Het is handig om dit dan via de FronController af te handelen, zodat je automatisch voor elke Action van de controller een eigen view script (template file) hebt.
die in hun eigen map van de Controller staan. (templates/Gastenboek/comment.php)
Quote:
edit:
Ik vind dit opzich wel een goed plaatje: MVC structuur
En dit is ook wel een makkelijk plaatje.
Ik vind dit opzich wel een goed plaatje: MVC structuur
En dit is ook wel een makkelijk plaatje.
Gewijzigd op 01/01/1970 01:00:00 door Arian Stolwijk
Arian schreef op 17.01.2009 10:24:
Nu ontbreekt het Model nog. Dit is een abstractie laag van de data. Bijvoorbeeld van een database tabel, met de methods fetchAll(), fetchRow($id), insert($data), update(), delete().
Om nog een stapje verder te gaan met je models, zou je voor elke rij een eigen object kunnen maken, en voor meerdere rijen (die je bijvoorbeeld met fetchAll) returnt een rowGroup object kunnen maken. Dat rowGroup object maak je dan 'iteratible' door de Iterator interface te gebruiken...
Om nog een stapje verder te gaan met je models, zou je voor elke rij een eigen object kunnen maken, en voor meerdere rijen (die je bijvoorbeeld met fetchAll) returnt een rowGroup object kunnen maken. Dat rowGroup object maak je dan 'iteratible' door de Iterator interface te gebruiken...
Ook hier is weer een design pattern voor, deze keer heb ik niet zo'n mooie beschrijving kunnen vinden maar Wikipedia legt het wel goed uit: http://nl.wikipedia.org/wiki/Active_record_patroon
Deze kwam ik nog tegen en is wellicht interessant voor de TS:
http://www.phpfreakz.nl/documenten/18-11-06/Presentatie_OOP.pdf
Zend Framework is een componenten framework, je kunt het als 1 geheel framework gebruiken maar je kunt er ook voor kiezen om er gedeeltes (componenten) van te gebruiken. Tevens heb je de mogelijkheid om het framework te gebruiken en voor sommige onderdelen je eigen classes in te zetten.
Het gebruik van een componenten framework biedt je meer vrijheid, het ligt alleen aan de programmeur of het nuttig gebruikt wordt of niet.
In phparch is vorig jaar een korte serie geweest waar 3 verschillende frameworks vergeleken werden om duidelijk te maken wat de verschillen waren. Het laat zien geen enkel framework heilig is, je moet gewoon gebruiken wat het beste past bij een taak. Maar een componenten framework als ZF is in ieder geval in mijn ogen wel een framework.
En hoezo denk jij dat het geen MVC voorbeeld is? Hier ben ik wel nieuwsgierig naar.
Omdat de TS specifiek vraagt naar een mappenstructuur/klassen opzet, dan ben ik van mening dat er betere voorbeelden zijn dan ZF welke ook de MVC onderdelen als components biedt. Hier vind hij moeilijk de informatie waar hij naar op zoek is.
Ik vond laatst trouwens een mooi artikel die een groot nadeel van ZF uit ligt... zal hem ff zoeken en bij een edit hier neer zetten
edit:
gevonden, merk op de chaos bij ZF:
http://phpimpact.wordpress.com/2008/08/04/php-applications-where-is-the-include-coming-from/
Gewijzigd op 01/01/1970 01:00:00 door M Ypma
ik dacht al dat het aan mij lag dat ik in m'n zend download erg weinig structuur (lees: mappen) aantrof, maar dat hoort dus zo.
is codeignitor een beter voorbeeld? ik heb deze een keer voor m'n neus gehad en die had duidelijk wel veel mapjes en structuur.
Ik heb de afbeeldingen van de verschillende pakketten bekeken
De meeste laden alles vanuit 1 of enkele bestanden, maar wie zegt dat het altijd nodig is. De structuur van requite/include heeft te maken met het feit dat er zo veel mogelijk geprobeerd wordt het pas te laden als het nodig is (oftewel niet gewoon alles in het geheugen stoppen zonder dat het zin heeft).
Ik vindt een mappen structuur van een applicatie niet zo heel spannend, het is veel belangrijker dat het classdiagram goed is. Als je een goede IDE hebt kan die je zo door de bestanden waar de classes staan linken.
Als je het class diagram van ZF bekijkt zie je zeer veel overerving wat een mooi principe is van OOP. Dat het daardoor gelaagd wordt en er soms op het eerste gezicht ingewikkeld uit ziet moet geen probleem zijn.
Dat het dan voor iemand die geen of weinig ervaring met OOP heeft misschien een lastig voorbeeld heeft klopt, maar dat komt niet omdat het niet klopt/slecht is. Juist doordat het meer kennis/inzicht in OOP verlangd.
Ivar ik denk dat het voor een framework belangrijk is dat je de eisen opstelt, een analyse doet en een technisch ontwerp maakt. De mappen structuur komt daarna en is vaak een kwestie van smaak.
Gewijzigd op 01/01/1970 01:00:00 door TJVB tvb
Ruby on Rails is bijvoorbeeld een invul-framework om het zo maar even te noemen. Symphony ook. Zodra je het installeert heb je al een werkende website, en die kan je uitbreiden door de juiste bestandjes in de juiste mapjes te gooien. Het voordeel is dat alles veel simpeler is omdat het framework al van een heleboel dingen uitgaat (de mappenstructuur, hoe requests worden afgehandeld, waar en hoe je model eruit ziet) en het nadeel is dat je moet voldoen aan die verwachtingen.
Is dit een aardige opzet? Zal ik voor iedere functie én een frontend én een backend class maken?
PS schrik niet, de download is voor eigen werk :D
Gewijzigd op 01/01/1970 01:00:00 door ivar