[PHP] MVC model, nog maals

[Sjoerd]

Inleiding:
Nu dat ik voor de 2maal in 2 jaar tijd mijn cms volledig heb geschreven omdat ik weer iets nieuws wilde (eerste keer was het zonder oop) nu wil ik graag alles herschrijven en gebruik maken van het MVC model + alles commenten zoals het hoort.

Dus een boek gekocht die verschillende patterns behandeld zoals factory, mvc,...
Ik ben ondertussen opnieuw begonnen en wel adhv deze tutorial voor de globale opzet:
klik
Ik heb mijn eigen registry class geschreven en ook de templates doe ik iets anders.

de structuur:

classes
-controller_base.php
-registry.class.php
-router.class.php
-template.class.php
-database.class.php
controllers
-index.php
-members.php
includes
-startup.php
-config.php
templates
-index.php
-members.php

Nu ontbreekt hier nog Models... dit omdat de maker van de tutorial het fijn vind de lijnen tussen controller en model te vervagen (eenvoudiger???).
Ik zou dus wel graag met models werken maar weet niet zeker of ik het goed heb begrepen.

De router zorgt ervoor dat deze de juiste controller oproept,
-de controller, roept het bijhorende model op.
-het model,voert queries uit op de database, returned bv een array met resultaten naar de controller --de controller verwerkt dit en output het naar de view
-de view geeft dan alles weer

Hoe zorg ik er nu effectief voor dat ik mijn juiste model oproep, deze includen? of hoe wordt hier normaal naar verwezen? (ik zoek dus de manier om in php de link te maken op een nette manier)

Excuses voor de mogelijk verwarrende uitleg

[Janoz]

Het model is de lijst met resultaten. De controler geeft alleen aan wat er aan de inhoud veranderd zou moeten worden, maar geeft het zo goed als rechtstreeks door aan de view.

[Cobalt]

Model elementen zijn entiteiten ofwel de klassen/objecten die de data bevatten. De view heeft meestal direct toegang tot de model elementen om ze weer te geven (ivm de preformance), het aanpassen gaat dan vaak via de controller (ivm logica, validatie, etc.). De controller zal dan de entiteiten aanpassen en ook bijv. een OR mapper aanspreken om de entiteiten in de database te zetten, updaten of op te halen.

[ Voor 6% gewijzigd door Cobalt op 23-06-2008 10:51 ]

[wackmaniac]

Sjoerd schreef op maandag 23 juni 2008 @ 09:39:-het model,voert queries uit op de database, returned bv een array met resultaten naar de controller

In mijn belevingswereld doet een model helemaal niets behalve data representeren. In zie het model zelf altijd als een object dat attributen heeft en getters en setters voor deze attributen en verder niets.

[Sjoerd]

Bedankt beide,

momenteel gaat het als volgt in de controllers (users.php):

PHP:

 function index() {
               registry::get('template')->set ('pagina', 'Users index pagina');
               registry::get('template')->show('index');
        }
        function view() {
             $data="";
             $db=registry::get('db');
         $sql = $db->prepare('SELECT * FROM users WHERE id<>?'); 
         $id=1;
         $sql->bindParam( 1 , $id ); 
         $sql->execute(); 
            
        foreach( $sql->fetch() as $row ) { 
                      $data.= $row['firstName']; 
       } 
       registry::get('template')->set ('testData', $data);
           registry::get('template')->show('index');
    
        }

Let vooral niet op de sql statement (eerste test met PDO vandaar)

Klopt het dan dat ik het stuk met de sql eigenlijk moet verhuizen naar "models/users.php"
en dan in "models/users.php" bv function getUsers(){..} en vervolgens in de controller (users.php)

PHP:

$data=$mUsers->getUsers();
registry::get('template')->set ('testData', $data);
registry::get('template')->show('index');

edit: Excuses als er ik nogmaals naast zit
aan de reactie boven mij, blijkt dat ik er dus wel naast zit weer... even nakijken dan nog waar de sql komt

[ Voor 5% gewijzigd door Sjoerd op 23-06-2008 11:23 ]

[PrisonerOfPain]

wackmaniac schreef op maandag 23 juni 2008 @ 11:04:
[...]


In mijn belevingswereld doet een model helemaal niets behalve data representeren. In zie het model zelf altijd als een object dat attributen heeft en getters en setters voor deze attributen en verder niets.

Over het algemeen doet het model wel meer als dat; zo bestaat het meestal namelijk nog uit een domain en data layerij de domain layer over het algemeen de wat complexere logica bevat.

Sjoerd schreef op maandag 23 juni 2008 @ 11:21:
edit: Excuses als er ik nogmaals naast zit
aan de reactie boven mij, blijkt dat ik er dus wel naast zit weer... even nakijken dan nog waar de sql komt

Die komt gewoon in de model layer. Als die layer simpel genoeg is kun je er voor kiezen om de data access en domain logic te verenigen in een class door middel van het active records pattern; en dat is in veel gevallen ook genoeg. Voor aggregate data of data die je op table niveau aan moet kunnen heb je ook nog het table data gateway pattern en voor individuele elementen het row data gateway pattern. Die laatste twee maken een explicieter scheiding tussen data access en domain logica dan active records maar het kan net zijn wat je nodig hebt.

[ Voor 44% gewijzigd door PrisonerOfPain op 23-06-2008 11:28 ]

[tweakerbee]

De naam model wordt volgens mij meer in Java gebruikt, de term die je afaik in PHP meer tegen zult komen is Value Object:

http://www.patternsforphp.com/wiki/Value_Object

[Janoz]

Value objects (of value transfer objects (VTO) of transfer objects (TO)) zie je ook erg veel in java. Er is echter wel een verschil tussen het Model en VO's. VO's bezitten enkel de data terwijl een Model ook functionaliteit bezit om state en statechanges bij te houden.

[THIJZEL]

Waarom probeer je niet gewoon een MVC framework als cakephp te gebruiken? Daarmee kan je ook meteen aan de gang met het maken van je applicatie ipv je druk te maken om het opnieuw bouwen van iets dat al bestaat.

[Sjoerd]

CakePHP heb ik al is bekeken maar het wiel opnieuw uitvinden is de manier waarop ik php probeer te leren (gaat tot nu toe vrij goed )

Ik heb al een hoop gelezen over verschillende db patterns maar echt een explictiet voorbeeld van
het active records pattern of hoe ik dit kan implementeren vind ik niet.

(overigens valt het me nu pas op, nu ik wat verder kom met php, dat nederlandse php sites/tuts nooit echt zaken als bijvoorbeeld het active records patern bespreken)

[Janoz]

Staar je niet te veel blind op design patterns icm php. Het enkel hebben van een requestscope beperkt de voordelen van veel design patterns.

[PrisonerOfPain]

Janoz schreef op maandag 23 juni 2008 @ 17:55:
Value objects (of value transfer objects (VTO) of transfer objects (TO)) zie je ook erg veel in java. Er is echter wel een verschil tussen het Model en VO's. VO's bezitten enkel de data terwijl een Model ook functionaliteit bezit om state en statechanges bij te houden.

Persoonlijk heb ik VO/VTO's nooit echt begrepen en ze doen me ook meer aan C denken dan menig andere programmeer constructie; iets wat voor een moderne object geörienteerde programmeertaal zeker geen compliment is. Gezien het feit dat in OOP eigenlijk alleen gedrag gespecificeerd word vind ik het sowieso vreemd om op een dergelijke manier met state rond te gaan slingeren.

Sjoerd schreef op dinsdag 24 juni 2008 @ 12:18:
Ik heb al een hoop gelezen over verschillende db patterns maar echt een explictiet voorbeeld van
het active records pattern of hoe ik dit kan implementeren vind ik niet.

Je noemde net CakePHP al en verder word 't in de literatuur omschreven door onder ander Fowler en Sweat. Het is een tijdje een vrij hot-topic geweest dus er is zeker voldoende over te vinden.

Janoz schreef op dinsdag 24 juni 2008 @ 12:50:
Staar je niet te veel blind op design patterns icm php. Het enkel hebben van een requestscope beperkt de voordelen van veel design patterns.

Waar haal je die wijsheid vandaan? Natuurlijk moet je je niet blindstaren op design patterns maar om te claimen dat dat te maken heeft met de requestscope vind ik enigszins vreemd. Zeker omdat je geen data persistence in de VM zelf hebt zul je veel meer serialization naar onder andere de database moeten doen en is het zodoende handig om je te verdiepen in patronen die daartoe relevant zijn.

[ Voor 20% gewijzigd door PrisonerOfPain op 24-06-2008 13:02 ]

[Janoz]

PrisonerOfPain schreef op dinsdag 24 juni 2008 @ 12:56:
[...]


Persoonlijk heb ik VO/VTO's nooit echt begrepen en ze doen me ook meer aan C denken dan menig andere programmeer constructie; iets wat voor een moderne object geörienteerde programmeertaal zeker geen compliment is. Gezien het feit dat in OOP eigenlijk alleen gedrag gespecificeerd word vind ik het sowieso vreemd om op een dergelijke manier met state rond te gaan slingeren.

Een VO is inderdaad ook niks meer dan een struct. Het is de exacte representatie van een entiteit zonder functionaliteit. Het wordt vaak gebruikt om heen en terug door de verschillende layers te gooien. Daarom wil je er eigenlijk ook geen echte functionaliteit in hebben. Weergave functionaliteit hoort enkel in de view layer terwijl persistency alleen in de datalayer hoort. Een VO wordt in beide lagen gebruikt, maar daar wil je niet beide functionaliteit in hebben.

Daarnaast specificeer je in OOP niet enkel gedrag. Het komt mij iig niet bekend voor. Het is inderdaad wel zo dat je bij OOP het gedrag samen met de data specificeerd, maar dat betekend niet dat al het gedrag bij al de data hoeft te staan. Veel gedrag van data is helemaal niet afhankelijk van de data, maar meer van de plek waarop de data gebruikt wordt.

Waar haal je die wijsheid vandaan? Natuurlijk moet je je niet blindstaren op design patterns maar om te claimen dat dat te maken heeft met de requestscope vind ik enigszins vreemd. Zeker omdat je geen data persistence in de VM zelf hebt zul je veel meer serialization naar onder andere de database moeten doen en is het zodoende handig om je te verdiepen in patronen die daartoe relevant zijn.

Designpatterns moet je ook zeker niet negeren! Wat echter wel belangrijk is is begrijpen waarom een designpattern gebruikt wordt. Ik zie tegenwoordig veel te veel mensen die designpatterns gebruiken omdat het designpatterns zijn, en niet omdat hun specifieke probleem opgelost zou kunnen worden door dat designpattern te gebruiken.

Designpatterns zijn tools en voor alle tools geldt : Right tool for the job.

Neem bijvoorbeeld MVC. Wat tegenwoordig vaak MVC genoemd wordt is eigenlijk geen MVC, maar PAC (Presentation-Abstraction-Control). PAC is best goed toepasbaar in php. MVC is dat niet. Bij MVC is het de bedoeling dat je je model vasthoud, ook over requests heen. Dat is in php zonder serialize en deserialize acties niet te doen waardoor het voordeel van het vasthouden gewoon al verdwenen is.

Een ander voorbeeld is het singleton pattern. Als je dat in php implementeerd krijg je alsnog elk request een andere instantie. Ook verschillende gebruikers krijgen verschillende instanties. En dat terwijl een voordeel van het singleton pattern juist is dat je maar een enkele instantie in je hele application scope zou kunnen garanderen.

Uiteindelijk zeggen we hetzelfde. Je moet goed kijken of een designpattern wel relevant is. Ik hoop echter dat ik heb kunnen aangeven waarom(bijvoorbeeld) de requestscope beperking van php het voordeel van designpatterns beperkt.

[ Voor 3% gewijzigd door Janoz op 24-06-2008 13:25 ]

[Sjoerd]

Dankzij deze discussie ben ik toch maar aan het overwegen of ik niet inderdaad gewoon een model ga gebruiken dat in mijn ogen goed is
En mijn huidige cms stilaan ga omvormen naar dat model dat ik wens.

[PrisonerOfPain]

Janoz schreef op dinsdag 24 juni 2008 @ 13:24:
[...]

Een VO is inderdaad ook niks meer dan een struct. Het is de exacte representatie van een entiteit zonder functionaliteit. Het wordt vaak gebruikt om heen en terug door de verschillende layers te gooien. Daarom wil je er eigenlijk ook geen echte functionaliteit in hebben. Weergave functionaliteit hoort enkel in de view layer terwijl persistency alleen in de datalayer hoort. Een VO wordt in beide lagen gebruikt, maar daar wil je niet beide functionaliteit in hebben.

Over het algemeen geef ik in mijn applicaties de view-layer gewoon toegang tot de model-layer (of specifieker, de domain layer in de meeste gevallen). Zodoende kan de view zelf nagaan wat 'ie wil weergeven zonder dat je op de controller (of een ander mechanisme) vertrouwd om de correcte data door te geven. Het geeft wellicht een hogere koppeling tussen de model en de view, maar dat is praktisch irrelevant aangezien het verkeer maar een richting op gaat. Kortom de model layer weet nog steeds niets van de view layer af.

Het grote probleem dat ik heb met VOs is dat je concrete objecten door je hele applicatie verweven zijn; abstracties maken van VOs is eigenlijk ook niet zinvol in de meeste gevallen omdat je dan abstracties maakt van de state / data van je applicatie en niet van de behaviour daarvan.

Daarnaast specificeer je in OOP niet enkel gedrag. Het komt mij iig niet bekend voor. Het is inderdaad wel zo dat je bij OOP het gedrag samen met de data specificeerd, maar dat betekend niet dat al het gedrag bij al de data hoeft te staan. Veel gedrag van data is helemaal niet afhankelijk van de data, maar meer van de plek waarop de data gebruikt wordt.

Natuurlijk specificeer je ook state in een OOP applicatie maar dat komt meestal pas ter zaken in de concrete implementatie. De abstractie daarvan specificeer namelijk wel enkel het gedrag van de objecten. Dat is gewoon klassieke data encapsulation; een abstractie die de specifieke state van een object irrelevant maakt. Het samenvoegen van state en gedrag is dan ook precies een van de punten waarom OOP überhaupt bedacht is.

Designpatterns zijn tools en voor alle tools geldt : Right tool for the job.

Een vaak gehoord mantissa en zeker ook niet minder waar. Echter heeft het een probleem, je moet bekend zijn met het gehele probleem domein en met een gigantisch aantal tools. Een van de manieren om er achter te komen wat de "right tool for the job" is, is om het in een scala aan van synthetische omgevingen uit te proberen en dat kan eigenlijk alleen met dit soort projecten. Zodra je dit in een productie omgeving uit gaat testen (behoudens prototyping) ben je compleet verkeerd bezig en kun je er donder op zeggen dat je je baan vrij snel kwijt bent. Verder is het zo dat de "right tool" ook simpelweg iets kan zijn waar je al mee bekend bent (zoals design patterns) omdat je dan weet dat je sneller klaar bent ondanks dat het misschien niet de optimale oplossing hoeft te zijn. Nou is dat natuurlijk geen vrijbrief om alles maar te misbruiken en niks nieuws te leren het wil gewoon zeggen dat de goede tool niet per definitie de perfecte hoeft te zijn.

Neem bijvoorbeeld MVC. Wat tegenwoordig vaak MVC genoemd wordt is eigenlijk geen MVC, maar PAC (Presentation-Abstraction-Control). PAC is best goed toepasbaar in php. MVC is dat niet. Bij MVC is het de bedoeling dat je je model vasthoud, ook over requests heen. Dat is in php zonder serialize en deserialize acties niet te doen waardoor het voordeel van het vasthouden gewoon al verdwenen is.

Erg bekend met PAC ben ik niet dus veel uitspraken kan ik daar dan ook niet over doen, daar tegenover staat ik wel vaak zie is dat er MVC gebruikt word met een Composite View; ergo enkel de view is hiërarchisch opgebouwd terwijl de model en de controller meestal gewoon 'plat' zijn.

Dat MVC niet geschik zou zijn voor PHP om de door jou aangehaalde reden vind ik toch apart aangezien het gehele MVC concept los staat van data persistency. Het specificeert namelijk enkel de interactie tussen drie enorm abstracte concepten en niet de implementatie daarvan.

Een ander voorbeeld is het singleton pattern. Als je dat in php implementeerd krijg je alsnog elk request een andere instantie. Ook verschillende gebruikers krijgen verschillende instanties. En dat terwijl een voordeel van het singleton pattern juist is dat je maar een enkele instantie in je hele application scope zou kunnen garanderen.

Dat de application scope en de page scope in PHP even lang duren wil natuurlijk niet zeggen dat je geen object zou willen kunnen hebben dat precies die duur heeft echter limiteert dit het aantal nuttige use-cases voor dat design pattern nogal.

Verder is het zo dat het singleton pattern erg hoog op mijn lijstje met anti-patterns heb geplaatst en dat komt eigenlijk alleen omdat ik er maar een, in mijn ogen, valide doel voor heb gevonden. Namelijk in C++, omdat de instansiatie volgorde van statics niet vast staat kan het zijn dat je het nodig hebt om een object 'automatisch' bij bijvoorbeeld een factory te registreren. Dat kan natuurlijk manueel maar dat levert over het algemeen meer werk op tijdens het gebruik van de factory; iets dat het in mijn ogen niet waard is.

Een ander argument tegen singletons zou kunnen zijn dat het een synoniem zou vormen voor globale variabelen echter hoeft ook dat niet in alle gevalen een probleem te vormen; zie bijvoorbeeld de Metaclasses zoals Smalltalk en Objective-C die kennen. Wederom zie je dan dat de "right tool" eigenlijk geen strikte definities kent en voor een heel groot deel gewoon op ervaring berust is.

Uiteindelijk zeggen we hetzelfde. Je moet goed kijken of een designpattern wel relevant is. Ik hoop echter dat ik heb kunnen aangeven waarom(bijvoorbeeld) de requestscope beperking van php het voordeel van designpatterns beperkt.

Uiteraard zeggen we bijna hetzelfde, de minieme verschillen zijn het die de discussie interessant houden