[oop] loading en object in view
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?
Ben ik ff blij dat Symfony zichzelf geen MVC framework noemt :)
Quote:
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? ;-)
Quote:
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:
Code (php)
1
2
3
4
2
3
4
<?php
$view_product = new ViewProduct();
$view_product->setName() = $product->getName();
?>
$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 :)
Code (php)
1
2
3
4
2
3
4
Model <----> View ----> Controller
^ |
| |
+-------------------------+
^ |
| |
+-------------------------+
MVP
Code (php)
1
2
3
4
2
3
4
Model <----> View <---- Presenter
^ |
| |
+-------------------------+
^ |
| |
+-------------------------+
MVA
Code (php)
1
Model <----> Adapter <----> View
MVVM
Code (php)
1
2
3
4
5
2
3
4
5
Model <----> ViewModel <-----> View
^
|
v
Controller
^
|
v
Controller
HTTP (aangezien Symfony dat is)
Code (php)
1
Request ----> Controller ----> Response
Gewijzigd op 13/05/2014 23:40:36 door Wouter J
Dat werkte zo toch?
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
Request
|
|
V
Route
|
|
V
Controller <----> Model
|
|
V
View
|
|
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?
Gewijzigd op 13/05/2014 23:22:46 door Ozzie PHP
Waar staat 'Presenter' voor?
Waar staat 'Adapter' voor?
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).
>> Ik vindt zelf dat ZF een MVA is...
Maar ook dat klopt niet helemaal, want de view praat niet terug richting de controller toch??
Dat komt omdat wij als PHP developers in de beperkte wereld van 1 richtingsverkeer werken. Deze patterns zijn allemaal UI patterns, ontworpen door mensen die computer programma's maken. Daarbij bestaat die pijl van view naar controller wel, denk maar aan het klikken op een button.
Ah ja... daar had ik inderdaad niet aan gedacht. Geinig :)