[PHP] MVC-pattern, meerdere views

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • SvMp
  • Registratie: September 2000
  • Niet online
Ik ben mij aan het verdiepen in het MVC-pattern. Ik ben een website aan het bouwen die ik zowel op huidige browsers als oude browsers (zonder CSS) als mobiele apparaten wil kunnen weergeven.

Hier gaan verschillende views voor zorgen.

Ik loop tegen het volgende aan: De controller start eerst een model, die de gegevens verzamelt en netjes ergens wegzet. Vervolgens wordt één van de views geladen die de gegevens gaat gebruiken.

Nou is het niet ondenkbaar dat op een mobiele versie van een pagina sommige info niet wordt weergegeven. Het scherm is kleiner. Die info hoeft ook niet verzameld te worden door het model. Het model heeft echter geen weet van views. Hoe kan ik het model duidelijk maken dat bepaalde info niet verzameld hoeft te worden? Als dit wel gebeurt, kan dit inefficient zijr voor vereenvoudigde versies van de pagina. Klopt het dat de controller aan het model doorgeven of er info is die niet verzameld hoeft te worden, aangezien het model zelf niets van de views weet, maar de controller info heeft van zowel view als model. Of kan dit nog anders opgelost worden?

Ik gebruik geen framework, schrijf zelf een aantal eenvoudige classes.

Acties:
  • 0 Henk 'm!

  • YopY
  • Registratie: September 2003
  • Laatst online: 10:07
Die info hoeft ook niet verzameld te worden door het model. Het model heeft echter geen weet van views. Hoe kan ik het model duidelijk maken dat bepaalde info niet verzameld hoeft te worden?
Nouja, wat vraagt aan het model om die gegevens op te halen? Juist, de controller. In de controller doe je logica dat bepaalt, aan de hand van bijvoorbeeld de user agent van de gebruiker, of je de volledige of een 'lite' versie wilt tonen, en aan de hand daarvan vraag je andere gegevens van het model op. Dus ja, dat klopt. Je model-laag weet niks (en moet niks weten) van noch waar de gegevens heengestuurd worden, noch hoe ze getoond moeten worden - dat zit hem volledig in de controller-laag.

Dus om je vermoeden te bevestigen: Ja, de controller. Daar stop je een switch in, mobile of niet, en aan de hand daarvan geef je een andere view terug (met andere data).

Acties:
  • 0 Henk 'm!

  • djluc
  • Registratie: Oktober 2002
  • Laatst online: 15:37
In veel gevallen maakt het niet uit hoeveel informatie je opvraagt. Een veld meer of minder is niet zo relevant meestal.

De controller weet welke view gerendered wordt dus die kan bepalen om informatie X of Y op te halen en door te sturen. Aan de andere kant kan een view ook gewoon gegevens opvragen bij een model, het is een driekhoek, geen lineaire opzet binnen MVC.

Acties:
  • 0 Henk 'm!

Anoniem: 178962

Je controller zou juist onafhankelijk moeten zijn van je view en je model. Die onafhankelijkheid van de verschillende onderdelen is juist de sterke kant van MVC. Je kunt een front-end progger/designer lekker in de view laten klooien terwijl de hardcore proggers de controller in elkaar zet. Het model kun je van te voren in je documentatie al vastleggen.

Het lijkt me dus niet handig om in je controller of je model te gaan kijken of een bepaalde view toevallig voor een mobiele browser is of niet. Dat het iets minder efficient is: Tjah MVC is juist niet geschreven om efficient te werken, het is geschreven om efficient te programmeren. Immers zitten de kosten vaak in het programmeren en niet zozeer in het laten draaien (bijschakelen van hardware is vele malen goedkoper dan bijproggen).

Acties:
  • 0 Henk 'm!

  • SvMp
  • Registratie: September 2000
  • Niet online
Dank voor de reacties.

Ik heb er nog niet bij stilgestaan, maar inderdaad die maximale efficientie is niet altijd de keuze. Aanleiding voor dit topic is een hobby-project, resources zijn beperkt, dus ik kies voor de maximale efficiënte. Als ik dit voor mijn baas deed, had ik waarschijnlijk in eerste voor snelle ontwikkeling gekozen. Wel valt het mij op hoeveel stroperige websites er zijn zonder dat er sprake is van een trage verbinding. Wat mij betreft mag er wel wat meer aandacht zijn voor efficiëntie.

Bovenstaande drie reacties leggen de nadruk alle drie compleet verschillend. Uitgaande van keuze om die server zo weinig mogelijk te laten zweten, kan ik twee mogelijkheden halen uit de posts van YopY en djluc:
1. De alwetende controller geeft de juiste info over wat wel en wat niet door aan het model
A. Controller heeft alle info (nadeel: als ik views verander, moet ik ook in de controller spitten)
B. View heeft info, controler vraagt deze op, roept method aan, vervolgens view.
2. De view vraagt zelf informatie op aan het model, en geeft daarbij uiteraard door wat wel en wat niet.

Volgens mij mogen beide mogelijkheden. De view heeft immers kennis van het model, de controller is alwetend.

Qua 'mooiheid' vind ik methode 1 mooier, view en method communiceren uitsluitend met controller, niet met elkaar.
Methode 2 vind ik praktischer: In sommige pagina's is juist geen sprake van verschillen, tussen andere weer wel. De view heeft al die informatie, en kan dus gemakkelijk de method benaderen.

Acties:
  • 0 Henk 'm!

  • Caelorum
  • Registratie: April 2005
  • Laatst online: 19:44
SvMp schreef op vrijdag 29 oktober 2010 @ 09:05:
1. De alwetende controller geeft de juiste info over wat wel en wat niet door aan het model
A. Controller heeft alle info (nadeel: als ik views verander, moet ik ook in de controller spitten)
B. View heeft info, controler vraagt deze op, roept method aan, vervolgens view.
2. De view vraagt zelf informatie op aan het model, en geeft daarbij uiteraard door wat wel en wat niet.
Je moet er juist voor zorgen dat het model niets anders weet dan de data. Het model hoort helemaal neits af te weten van hoe de data moet worden gepresenteerd. Dat is een taak voor de view.
De controller is verantwoordelijk voor de juiste data bij de view te krijgen. De view om deze data al dan niet correct weer te geven.
Wat je overigens ook kan doen is de controller een viewmodel aan laten maken met data welke bij een specifieke view hoort. De view heeft dan alleen weet van een container met data welke nodig is. Op die manier forceer je dat de controller verantwoordelijk is voor het "filteren" van de model tot data die de view hoort te weten.

Wat je overigens ook kan doen voor het al dan niet weergeven van data is:
1) De controller bepaalde views laten genereren op het al dan niet mobile zijn. Is volgens mij al eerder genoemd in dit topic.
In dat geval heb je misschien een overzicht van gebruikers: UsersListViewMobile en UsersListView
Welke beide views zijn die door de UsersList methode van de controller kunnen worden aangemaakt.
2) 1 view maken met daarin beperkte logica in de trand van
code:
1
2
3
if(viewmodel->isMobile())
//laat dit zien
);

[ Voor 18% gewijzigd door Caelorum op 29-10-2010 10:09 ]

Pagina: 1