[Nihilnovi]

Model och view ska inte ha med varandra att göra alls i MVC.

Controllern ska skicka info till model som den behöver för att hämta det som applikationen ska ha.

Modeln skickar denna information till Controllern, denna ska då kolla om det är rätt info och möjligtvis utföra nån slags operation på den innan den skickas till viewen. Viewen ska BARA visa informationen, absolut inte utföra någon slags logik på den.

Var javascript har sin plats i det hela är en smaksak. Vad jag själv gör är ett ajax anrop med ett ID och operation som ska utföras på detta ID till en controller. Denna granskar då vad som ska göra och om ny data från modeln behövs för att utföra denna information så ordnar den det innan resultat skickas tillbaka till viewen.

Controller = logik
Model = springpojke (ingen logik)
View = det användaren ser som et resultat av vad controllern bestämmer baserad på informationen den får

Dock så måste jag påpeka att det finns lika många tolkningar på MVC som det finns hemsidor på nätet, detta är bara min tolkning =)

[qson]

Ursprungligen postat av Nihilnovi

Model och view ska inte ha med varandra att göra alls i MVC.

Visst, detta har jag förstått

Bara för att förtydliga: Denna tråd gäller alltså en MVC-struktur i Javascript.
Model, View och Controller är alltså javascript-objekt/klasser.

Controllern ska skicka info till model som den behöver för att hämta det som applikationen ska ha.

Detta är så som jag har det nu...
En metod i controllern som anropar Model.getData() som returnerar informationen till controller.

Modeln skickar denna information till Controllern, denna ska då kolla om det är rätt info och möjligtvis utföra nån slags operation på den innan den skickas till viewen. Viewen ska BARA visa informationen, absolut inte utföra någon slags logik på den.

Precis. När controllern får svar från Model skickar den informationen till View för presentation.

Var javascript har sin plats i det hela är en smaksak.

Nja, hela MVC-applikationen är skriven i Javascript så det är ingen smaksak

Vad jag själv gör är ett ajax anrop med ett ID och operation som ska utföras på detta ID till en controller.

I mitt fall är det min Model som gör ett AJAX-anrop (vid behov).

Denna granskar då vad som ska göra och om ny data från modeln behövs för att utföra denna information så ordnar den det innan resultat skickas tillbaka till viewen.

Detta gäller ju AJAX-servern (t.ex. i PHP) så det är inte aktuellt i mitt fall.
MVC i PHP har jag koll på :-)

Controller = logik
Model = springpojke (ingen logik)
View = det användaren ser som et resultat av vad controllern bestämmer baserad på informationen den får

Indeed!

Dock så måste jag påpeka att det finns lika många tolkningar på MVC som det finns hemsidor på nätet, detta är bara min tolkning =)

Visst finns det många tolkningar.
Jag hittade denna artikeln som beskriver det hela på ett ganska bra sätt.
http://www.alistapart.com/articles/javascript-mvc/

--

Hur det blev till slut:
Controller anropar Model att hämta data.
Controller behandlar datan och skickar till View för presentation.

I ett formulär ändras informationen för en markerad post:
Controller.update anropas.
Controller anropar Model.update(id,data) för att spara.
Controller anropar View.update(id,data) för att visa ändringen.

[dAEk]

Ursprungligen postat av Nihilnovi

Controller = logik
Model = springpojke (ingen logik)
View = det användaren ser som et resultat av vad controllern bestämmer baserad på informationen den får

Dock så måste jag påpeka att det finns lika många tolkningar på MVC som det finns hemsidor på nätet, detta är bara min tolkning =)

Normalt brukar man säga att (C)ontrollern är som en trafikpolis/dirigent. C gör inget arbete själv utan ser till att indata/anrop är i rätt format, kopplar ihop dem med en (M)odell som sedan gör jobbet (affärslogiken). När M sedan är klar och returnerar data till C dirigeras den (datan) vidare till lämplig View.

Namnen Model, View och Controller förklarar sig själva ganska bra. Att säga att logiken skall göras i Controllern och inte i Modellen tycker jag tyder på att man har en helt felaktig bild av hur MVC-mönstret funkar.