MVC/Design-fråga, PHP

Allså, en modell ska innehålla massor med data, en view ska visa datan men inte interagera med modellen, en view kan aktivera en kontroller som kan förändra antingen view:en eller datan i din modell.

Ska göra en bild...

Har själv pysslat med MVC, en hel del faktiskt. Håller med om att det är svårt att hitta bra resurser och guider, men det beror nog mycket på att MVC är ett abstrakt mönster som kan implementeras på olika sätt.

I ditt fall så tror jag att pull är att föredra framför push (dvs att vVisartikel själv hämtar data från modellen). Frågan är annars varifrån parametern till Viewen-lagret skall skickas.

Såhär tolkar jag att MVC skall (kan) implementeras

• Controller - Sköter validering av användarinput, ändrar och uppdaterar modellen samt väljer view

• Model - Interagerar med databasen, filsystemet eller andra databehållare

• View - Hämtar den data som behövs från modellen, och renderar datan (utefter en template

Viewen består alltså av två delar, en del som hämtar data ur modellen och en template som tala om hur datan skall renderas. För att behålla separationen är det viktigt att viewen INTE ändrar eller uppdaterar modellen.

Genom ovanstående uppdelning där kontrollern väljer view, men inte skickar med data till Viewen kan ju alla Views användas från alla controllers (viewen vet ju vad den skall visa, det är onödigt om controllern skall behöva hålla reda på det).

Ett konkret exempel på när det kan bli problem med push metoden är om du har sammansatta vyer (composite pattern). Säg att du på varje sida har en sidebar med senaste nyheter. Om sidebaren är en egen view så kan den inkluderas i en annan view och på så sätt visas på alla sidor. Då är det mer praktiskt om viewen själv hämtar sin data.

Angående länktips så delar jag gärna med mig av de jag har

• To hopefully clear up some MVC confusion

• WACT Model View Controller Pattern - Beskriver grundläggande MVC samt vad de olika delarna har för relation till varandra

• SItepoint - PHP application design forum - Sök på MVC i forumet, det finns massor av bra trådar och tankar. Lägg speciellt märke till det Kyberfabrikken skriver. Det finns även ett par till MVC gurus där.

• Martin fowler - Om MVC

• Joe Stump - Understanding MVC in PHP - Ett konkret exempel på hur MVC kan implementeras

Rent genrellt kan jag säga att det är bäst att starta i liten skala och verkligen tänka till och därefter bygga ut det. Kom också ihåg att MVC i grunden är ett designmösnter som svarar på hur en applikation skall fungera, inte hur den skall implementeras.
Ofta kommer man också i kontakt med andra designmösnter (patterns) när man läser om MVC. För att lära sig mer om dem så rekomenderar jag sitepoints forum (se ovan) samt http://www.devshed.com/ för exempel på implementationer.

Undrar du något mer så hojta till!

Jag håller inte riktigt med om att modelen känner till viewen, anser att det skall vara tvärtom, något sånt här

Problemet med ovanstående är dels vem som skall skicka datan? Borde väl vara controllern då?

Sen är det svårt att fritt använda olika views från vilken controller som helst. Viewens uppgift är att hämta och visa information.

Har du något exempel på när man vill använda samma view med annan data?

Vanligaste implementationen är att vyn inte känner till modellen överhuvudtaget, kontrollern tar helt hand om kommunikationen mellan vy och modell, de känner aldrig till varandra.

Tycker denna variant är snygg då det separerar datalogik och visning ganska bra, bara i kontrollern som de samlas litegrann, men inte så mycket.

Utveckla gärna.

Låt oss säga vi har en sajt som visar saker från en databas, hur ska vyn då få data från modellen? Ska man skapa ett nytt objekt som man sedan skickar vidare till vyn då eller (låter helknasigt)?

Precis.

När jag tänker efter så når man för det mesta modellen direkt från vyn också, men tycker det är snyggare att hämta den i kontrollern och skicka upp till vyn därifrån.
Förutsatt att man inte behöver loopa två gånger för att hämta all data, då.

MVC handlar ju i grunden om att separera programlogik (kontrollern) från data (modellen) till visning (vyn). Varje komponent ansvarar för sin del. Kontrollern skall således bara hantera användarinput, uppdatera modellen (om det behövs) och sedan välja vy. Vyn kan sedan själv ansluta till modellen om den behöver det.

Delarna är löst sammankopplade. Modellen är helt fristående, den känner inte till någon annan, men både kontrollern och vyn känner till modellen. Kontrollern känner till vyn, me vyn känner inte till kontrollern. Kontrollern väljer endast vy, den interagrerar inte med den.

Det gör att vilken vy som helst kan användas från vilken kontroller som helst. Vyn vet ju vilken data den måste ha, då är det onödigt att kontrollern skall skicka med den när vyn kan hämta den själv.

Jag ser det som att vyn består av två delar, dels en del som hämtar data från modellen osv, och en template engine som renderar datan utifrånen template (templaten innehåller bara presentationslogik)