[qson]

Håller på med en webbapplikation med ett försök till MVC-struktur.
Har en "huvud"-controller (FrontController?) och sedan ett antal underkontroller för varje modul/del i applikationen.

Sedan har jag en "Model" som hämtar data med AJAX och flera "views" som hanterar det som syns.

Jag har t.ex. ListController, ListModel och ListView som visar produkter i en tabell.
ListController skapar instanser av ListView och ListModel, hämtar data från ListModel och skickar dem till ListView för visning.
Detta funkar utmärkt men nu har jag börjat fundera om det är något som fattas...

Om jag vill ändra/uppdatera informationen för en produkt i ListView så känner jag att jag måste gå via ListModel för att uppdatera informationen och sedan skicka ändringen till ListView för att presentera.
På något sätt måste jag då ha en referens för varje post i ListView till dess motsvarighet i ListModel så jag kan uppdatera en enskild post utan att rendera om hela ListView.

Hur ska man tänka här?

[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.

[Magnus_A]

Om du har mycket logik så kan man ha en actionhelper som ligger mellan controller och model för att behandla data, speciellt om flera olika actions använder sig av samma algoritmer.
För att hantera repetitiva uppgifter i samband med visning kan man ha en viewhelper som fixar formatering till exempel.

[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.

[Magnus_A]

Finns olika filosofier.
FatControllerSkinnyModel där man lägger logiken i controllern, och
SkinnyControllerFatModel där man flyttar ut logiken till modelen, som du föreslår.

Själv föredrar jag att lägga logiken i en Helper, så blir både Controller och Model magra.

Nånstans måste ju logiken ligga.

Apropå filosofier är de nog ingen slump att alla demos för MVC frameworks handlar om bloggar där man bara skyfflar data rakt ut på sidan, utan logik. Det är när logiken kommer in som det blir krångligt och man måste börja kompromissa.
Typ att man har liknande logik i ett par tre olika controllers/models, ska man då göra specifika funktioner i var och en, eller en generell men lite krångligare i en helper som alla kan anropa? Inget enkelt svar. När man börjar ändra visar det sig om man tänkt rätt eller inte.

[dAEk]

Vad skulle vara bra med att lägga affärslogiken sina controllers? Jag har svårt att se eventuella fördelar.

Några nackdelar kan jag komma på:

1. Det blir tight coupling mellan modellen och controllern.
2. Det strider mot SoC (Separation of Concerns) och SRP (Single Responsibility Principle).
3. Koden tenderar att bli rörig och svårhanterlig - speciellt om det är flera utvecklare i projektet. Metoderna blir långa och krångliga. De flesta av oss är inte så disciplinerade att vi klarar av att hålla blandningen mellan model- och controller-kod på en lagom (vad det nu innebär) nivå.
4. Unit-testing blir svårare.