Door
Ozzie PHP
op 12-05-2014 21:52
gewijzigd op 12-05-2014 21:52
4.605 views
Hoi allemaal,
Ik heb 2 OOP vragen, die enigszins met elkaar hebben te maken.
1) Loading
Als we een object hebben, bijvoorbeeld een product, dan kunnen we dat product laden met een mapper. Bijvoorbeeld:
<?php
$product_mapper = new ProductMapper();
$product = $product_mapper->load(12);
?>
Maar wat als we in plaats van één product bijvoorbeeld de 10 laatste toegevoegde producten willen tonen? Hoe werkt dat dan? Gebruiken we daar diezelfde mapper voor? Ik neem aan van niet, want we gaan niet ieder product stuk voor stuk uit de databse ophalen. Maar hoe dan wel?
2) Object in view
Stel ik heb een product ingeladen, hoe krijg ik dan de productinformatie in de view. Ik heb me ooit eens laten vertellen dat je in een view geen objecten mag gebruiken, omdat een view geen "intelligentie" mag bevatten. Dit zou volgens diegene dus niet mogen:
"Oké... dus Model en Mapper zijn gewoon hetzelfde?"
Nee een Mapper, een Data Access Object, een service (authenticatie, autorisatie, etc), factories etc kun je allemaal in de "Model" laag/categorie/whatever plaatsen.
De software industrie en Microsoft zijn ook niet het zelfde. Helpt dat iets? Je bent appels en peren aan het vergelijken.
Het irritante is dat de meeste "MVC" PHP frameworks geen MVC frameworks zijn maar een variant zoals bijvoorbeeld Model-View-Presenter, Model-View-Adapter, Model-View-ViewModel of Presentation-Abstraction-Control.
Lees 4 dagen lang eens elke dag elk van de wikipedia pagina's. Neem daarna de documentatie van populaire "MVC" PHP frameworks eens door om zelf te bepalen welke aanpak er daar gebruikt wordt. Ik vermoed dat er aardig wat MVP zijn.
Je vocabulaire is aardig gevuld :-) , Ik weet waar MVC voor staat maar al die andere typen zou ik echt niet weten. Is het echt nodig om al die wiki's door te pluizen of ben jij bereid om hier de belangrijkste verschillen te benoemen?
[offtopic]Ben ik ff blij dat Symfony zichzelf geen MVC framework noemt :)[/offtopic]
In je voorbeeld heb je het over een PageViewModel en in het codevoorbeeld over een PostViewModel. Is een van beide een verspreking?
Ach, what's in a name? ;-)
Ik snap alleen nog niet hoe het werkt zo'n DTO. Stel je wil een aantal producten tonen. Is dan de bedoeling dat de productgegevens uit de database haalt? Dat je hier normale productobjecten van maakt, en dat je dan vervolgens aan de hand van deze objecten een array gaat maken met speciale ProductViewModels, die in feite hetzelfde zijn als de normalen Product objecten, maar dan zonder setters? Begrijp ik het dan goed?
Jup. Dat is precies wat een DTO doet: Het transporteert de data van de ene laag (de Application laag) naar de andere (de View laag), zodat de lagen geïsoleerd zijn en elkaar niet kunnen beïnvloeden. Stel ik verander toch iets in de View laag, dan wordt dat gelukkig niet ook veranderd in de Application laag.
>> En jij geeft zelf al aan dat je KISS zou toepassen. Jij bent dus ook voorstander om gewoon de productobjecten zelf in een view te gebruiken?
Dat ligt eraan. Als je een site zoals deze maakt, gewoon lekker doen. De kans dat deze site ooit van concept gaat veranderen is klein. Maar ben je met iets meer complexere websites bezig of projecten die iets sneller kunnen veranderen, dan is het zeker wel eens de moeite waard na te denken over DTO's. Ben je bezig met je framework, dan werk je als het goed is helemaal niet op de Application en View laag, dus heb je hier geen zorgen over.
Ik raad je sowieso aan jezelf in te lezen over Domain Driven Design.
>> Ik weet waar MVC voor staat maar al die andere typen zou ik echt niet weten. Is het echt nodig om al die wiki's door te pluizen of ben jij bereid om hier de belangrijkste verschillen te benoemen?
Ja, dat zou zeker wel fijn zijn en helpen.
@Wouter:
>> Stel ik verander toch iets in de View laag, dan wordt dat gelukkig niet ook veranderd in de Application laag.
Ik snap wat je bedoelt. Bij een website is de view laag sowieso de laatste laag, dus in feite kun je dan niet echt veel meer veranderen lijkt me? Maar om nog even terug te komen. Je haalt de gegevens van bijv. 10 producten uit de database. Stop je die dan eerst in "normale" Product classes en ga je vervolgens die ProductView classes vullen vanuit de "normale" Product classes? Dus anders gezegd, maak je een foreach loop waarin je dit zet:
<?php
$view_product = new ViewProduct();
$view_product->setName() = $product->getName();
?>
OF... stop je de gegevens uit de database direct in de ViewProduct classes?
>> Ben je bezig met je framework, dan werk je als het goed is helemaal niet op de Application en View laag, dus heb je hier geen zorgen over.
In het framework niet, maar als je een website gaat maken natuurlijk wel :)
Wouter, onder welke categorie viel Zend Framework 1.0 dan eigenlijk?
Dat werkte zo toch?
Request
|
|
V
Route
|
|
V
Controller <----> Model
|
|
V
View
Dus je krijgt een request binnen. Aan de hand van het request wordt een route bepaald. De route wordt gekoppeld aan een Controller. De Controller haalt data op uit het Model en stuurt deze data door naar de view. Onder welke categorie valt deze werkwijze dan?
>> Wouter, onder welke categorie viel Zend Framework 1.0 dan eigenlijk?
Het routing verhaal staat hier even los van, aangezien de meeste patterns zijn uitgevonden voor talen voor computerprogramma's, daarin heb je geen request/response flow, maar slechts events in je view die een controller/adapter aanroepen. Vandaar dat de meeste patterns ook pijltjes hebben van de view naar de model/controller.
Ik vindt zelf dat ZF een MVA is, de Controller (Adapter dus) ligt tussen de view en het model in en heeft zelf geen logica. Aan de andere kant mag de view mag niet direct met de model communiceren (dus het is geen MVC).