Fat controller skinny model vs reverse
 

Ukratko, Sta vi preferirate i zasto ??

O ovoj temi se dosta diskutuje, uglavnom dosta ljudi brani
"fat model skinny controler" pogotovo iz rubi zajednice.

Ja koristim obrnut metod i modele koristim iskljucivo kao ORM-bas kao sto se ne preporucuje :)

Pa da li bi neko ko zagovara "fat model ..." mogao da mi posjani zasto treba da sledim takvu organizaciju.

Ja se ne bavim prevashodno webom, a i to što se bavim, radim neke ne baš klasične MVC aplikacije, uglavnom sa mikrofrejmvorcima. Tako da je moj odgovor više iz tuđih iskustava i nekog zdravorazumskog posmatranja.

Ima masa članaka po netu na tu temu. Generalno, argumentacija se svodi na reusability koda (isti model koristiš iz više kontrolera i view-ova), lakše testiranje i održavanje itd. U suštini, ista je priča kao sa objektnim programiranjem - objekat enkapsulira podatke i operacije nad njima.

U svakom slučaju, super je što uopšte razmišljaš o svom kodu, to je već pola posla. :)

Kratak odgovor: Zbog fleksibilnijeg dizajna koji dobijaš enkapsulacijom poslovne logike i razdvanjanjem odgovornosti između komponenti sistema.

Dugačak odgovor:
Prvo primer: Razvijaš aplikaciju za manipulaciju izborima :). Potrebno je da vodiš računa o trenutnom stanju na glasačkim mestima i da generišeš izveštaje operateru koji koristi aplikaciju. Ukoliko stranka gubi izbore operater može preko tvoje aplikacije da prebaci novac sa offshore stranačkih računa na račune korumpiranih posmatrača, glasača, brojača i sudija. Takođe mora da vodi računa o tome koja korumpirana osoba je odgovorna za koje biračko mesto.

Osnovni entiteti su ti BirackoMesto, Operater, Stranka, Racun, Posmatrač, Glasač, Brojač, Sudija, itd.

Imamo osnovne slučajeve korišćenja: Ažuriranje stanja sa biračkog mesta, Pregled odnosa između stranaka, Transfer novca sa računa na račun, Generisanje izveštaja o troškovima, itd.

Sve je ovo osnovna logika sistema (poslovna logika) koju ti nekako moraš da modeluješ svojom aplikacijom. Pokušaj da posmatraš razvijanje ove aplikacije van okvira tvog frejmvorka i van okvira web aplikacija uopšte. Posmatraj samo logiku sistema jer je to jezgro onoga što moraš da implementiraš.

BirackoMesto mora da poseduje operacije za vraćanje informacija o trenutnim glasovima, koji posmatrać je zadužen za to biracko mesto, da genriše izveštaj o ukupnom trošku za to biračko mesto itd.

Takođe i ostali entiteti bi trebalo da imaju operacije koje obavljaju funkciju koja je usko vezana za te entitete.

Na ovaj način možeš da razvijaš aplikaciju koristeći osnovne entitete i neke pomoćne kao što je na primer klasa TransferNovca koja enkapsulira logiku transakcije sa računa na račun. Objektu te klase proslediš račun sa kog prebacuješ, račun na koji prebacuješ i količinu novca a on sadrži svu logiku prebacivanja tog novca.

Ovakav dizajn ti omogućava veću fleksibilnost jer na primer možeš da iskoristiš postojeću logiku adaptiranjem postojeće klase. Na primer TransferNovca u klasu SiguranTransferNovca koja je zadužena za prebacivanje novca na način kojem se ne može ući u trag.

Ako primećuješ nigde nisam spomenuo kontrolera. Kontroler je za implementaciju aplikacione logike nepotreban.

Kontroler je koristan kod implementacije REST, a samim tim i HTTP aplikacija. Tvoja REST aplikacija mora da prihvati zahtev, na osnovu parametara zahteva izvrši određenu funkciju (logiku) sitema i da sve to lepo prezentuje.

Zato se odlučujemo za MVC pattern. Controler prima zahteve i na osnovu parametara instancira Model(e) i renderuje View koji je vezan za te Model(e).

Ovakav dizajn omogućava lakše testiranje aplikacije. Logiku sistema možeš da izvršiš nezavisno od interfejsa u koji je ona uključena. Odnosno, ne moraš da lažiraš HTTP zahteve, što omogućava lakšu automatizaciju testiranja.

Aplikaciju možeš brzo da adaptiraš za upotrebu u desktop, web, console, mobile aplikacijama.

Što se tiče ORM-a on je samo to što mu ime kaže mapiranje objekata u relacioni sistem. Predstavlja samo sloj između objektno orijentisanog koda i relacionih baza podataka jer su to dva veoma različita sistema.

Česta je zabluda da se dobro OOP svodi samo na primenu osnovnih pojmova objektno orijentisanog dizajniranja(OOD) (abstrakcije, enkapsulacije, polimorfisma i nasleđivanja). Pored ovih teorijskih pojmova postoje i osnovni principi koji predstavljaju vodilje prilikom osmišljavanja praktičnih rešenja (Googluj Object Oriented Principles).

Fat Controler krši nekoliko OOD principa. Ali mnogo sam već napisao tako da ću ovde da stanem.

Po meni kod klasicnog MVC-a ne treba nuzno jedan da bude fat, a drugi skinny, nego treba razdvojiti logiku na na ono sto se tice konkretnog zahteva (to ide u konktroler) i opstu logiku (to ide u model)... obicno je onda tu model "deblji", jer se dobar programer uvek trudi da generalizuje resenje..

Mada kad imas HMVC model (mogucnost slanja internih redirekta unutar aplikacije) kao recimo u Kohani, onda postoji mogucnost i da se kontroleri visestruko koriste, pa onda sva logika moze da se gurne u kontroler, a da model bude cisti ORM.

A opet imas i drugacije MVC gde view komunicira sa modelom direktno da bi dohvatio podatke (na primer Vivvo CMS je tako projektovan) sto ima svojih prednosti, a u tom slucaju je kontroler skinny, a model mora da ima svu logiku u sebi...

Hm.. Dakle, vidim da je glavna poenta:

Lepo receno, hvala :)

Sto se tice pisanja automatizovanih testova tu je jasno da je bolje da je fat model, al reusability .. i ne bas iz mog iskustva :)
Da ne bi samo pisali teoriju dodacu neki dummy kod:

Ovako izgleda moj klasican model. Odradi se selekt podataka i vrati rezultat, obicno stavim da se proslede neki parametri, tipa: where, order, limit, itd.
Dok kontroler primi request obrati parametre, odradi upite na bazu koje treba i vrati rezultat u view.
Kod nije ispravan, sad sam ka sklepao cisto primera radi, Zend framework je u pitanju. Model ima funkciju "getEvents(...)" koji vraca podatke iz baze, sva ostala obrada podataka if()else() i dr. je u kontroleru.

E sad, da li bi bio ispravan primer Fat modela da sam u kontoleru stavio:

$event_model = new Application_Model_Event();
$this->view->events = $event_model->getEvents($_POST);

i time prepustio apsolutno sve na modelu ???

Iz mog gledanja reusability bi se smanjio jer bi ta funkcija radila samo za odredjene slucajeve(verovatno samo za jedan), dok bi za druge kontrolere morao da pisem novu funkciju "getEventsOther(..)" po nekim drugim kriterijumima, koja bi se razlikovala od prve za 20%, a DRYS postujem vise nego ista :D

Ne znam dal sam lep primer naveo, al bi voleo da vidim neki konkretan kod koji bi pokazao Fat model, po mogucstvu klasicne CRUD aplikacije.

Hvala na odgovorima, inace ova tema me muci vec duze vreme :)
Radio sam u timovima gde smo radili i sa fat modelima, jednostavno mi se to tad nije svidelo ...

nikad nemoj praviti metod u modelu(ili bilo gde) koji direktno cita $_POST, napravi da ocekuje niz kao ulazni parametar, i onda mu prosledi $_POST.. onda sutra mozes da mu prosledis i $_GET, ili niz podataka koji je na neki drugi nacin skupljen (iz fajla, baze, ..)

takodje ja ne bih stavio u model nesto sto barata sa view-om, to onda nije MVC, nego klasican monolitni stil, samo si ga izdvojio u zasebnu klasu koju zoves modelom...

Po meni "pravilna" upotreba modela je da metode modela dobijaju neke argumente i onda radi jednu od dve stvari (ili obe):
a) izmeni podatke vezane za model (u bazi, fajlu, ili vec gde se cuvaju)
b) vrati neki rezultat

i to je to.. odakle dolaze ulazni podaci i gde se oni dalje setuju, to je posao konktrolera da definise... zato se i zove kontroler..

Naravno, pravilno je sve sto radi dobro u konkretnoj situaciji, tako da sve ove savete treba uzeti sa rezervom... to sto je nesto zgodno u 99% situacija uopste ne znaci da tebi mora da bude zgodno u nekom konkretnom slucaju...

ovo je sustina, nije bitno sta je debelo a sta mrsavo. sve to zavisi od konkretne situacije

Ovo što si okačio nije fat controller, ovo je baš kako treba. Fat controller je kad u kontroleru imaš logiku za npr "top 10 najposećenijih eventova". Na takve stvari se obično misli da treba da idu u model kad se kaže fat model. Nikako da $POST ide direktno u model.

I ako uzemo konkretan primer da se radi sa bazom u 80% slucajeva na webu se svodi na CRUD aplikacije:

izmena podataka + vracanje rezultata = orm ili malo vise od toga, ali nije ni blizu da je model tezi od kontrolera ...

Mislim da ovde malo mešaš babe i žabe, tj. poistovećuješ "debljinu" sa brojem linija. To što kontroler ima više linija koda od modela ne znači da je "deblji". Pored toga, različiti frejmvorci (i različiti jezici) pružaju mogućnost da se neki kod piše kraće, imaš mogućnost da koristiš razne helper metode itd, tako da isti taj tvoj primer kontrolera:

U nekom drugom hipotetičkom (khm) frejmvorku može glasiti:

itd.

To takođe zavisi i od toga kako si nazvao i organizovao form elemente, kako si osmislio rute itd, dosta tog "plumbinga" u kontroleru načelno može da se izbegne.

Može neko objašnjenje zašto nikako POST u model? Gde vi radite preveru i sanitizaciju podataka iz POST-a, u kontroleru?

Ne znam šta ti je to "sanitizacija". Konvertovanje parametara iz stringova u štagod treba modelu (npr u datum) obavljam u kontroleru. Logičku validaciju podataka vrši model.

Ja uglavnom 90% validacije obavljam u kontroleru, jer ako neki podatak nije validan i treba da se izbaci greska sto bi uopste skripta ulazila u metodu iz modela.

Sto se tice slanja $_POST u model, radio sam na kodu gde je slucaj ovakva:

Polja na formi se nazovu isto kao i polja u bazi, i tako da kad se post prosledi modelu
moze odmah da se uradi insert(selekt i dr.) jer je niz koji je key => value vec u postu.

Sve je secure tu nema sta, al jednostavno nisam za to, jer potencjalni napadac moze da izvuce koliko toliko semu baze, jeste da ne moze nista al mi se to ne svidja.
Ako neki junior sutradan treba da nesto dodaje/oduzme radice copy-paste i moguce da ce negde da zajebe nesto.
Citljiviji mi je kod ako u kontroleru pripremim post i samo odredjene parametre prosledim u model.

Ja mislim da ovo nije skoro nikad dobro resenje - validacija je usko povezana sa logikom modela (datum moze biti validan za jedan model a nevalidan za drugi itd.) i ovo jednostavno treba da bude enkapsulirano u modelu. (Rails npr. sve validacije stavlja u model i ne pozivaju se eksplicitno nigde, nego postoji konvencija kako se vraca greska, Django ima Form klasu koja ja usko vezana sa modelom i vrsi validacije, i model ih moze imati vise).

Sve ostalo skoro 99% sam siguran vodi ka ruznom kodu i izuzetno smanjenom re-usabilitiju.

Validacija u kontroleru mi ima smisla samo ako se radi o nekoj app-wide vrednosti koja nije konkretno vezana za neki model koji ce kasnije postati record u bazi.

Zar ne bi onda bas zbog toga validaciju prepustio kontroleru da ne bi u modelu morao da pises
if(datum1){validacija 1}else{validacija 2}

Upravu si kad kazes da je validacija povezana sa modelom ali hendlovanje greske u PHPu nije (u railsu je kako kazes drugacije).

Zend koji ima svoju klasu za forme i validacija toga se radi u kontroleru (koliko se secam tako je bilo i u drugim PHP FW).

Kad kazes za Zend - radi se validacija da li mislis na nesto ovako u kontroleru (fiktivni kod ali ovako se slicno radi u Django-u) :
Jer ako na to mislis - to je samo pozivanje validacije iz kontrolera i to je okej. 'validate' metoda forme (u ovom slucaju) radi validaciju i ovaj pattern osim ako ne zelis da ga customizujes moze biti i implicitno pozivan.

Ako mislis da code validate metode (u ovom slucaju) treba da pripada kontroleru - ne slazem se... mada mogu da zamislim frejmvork koji je tako koncipiran da validaciju vrsi u kontroleru ali mi se cini kao losiji pristup dizajnu od ovog... bar konceptualno.

Mesanje ova dva pristupa je svakako lose.

Da, bas tako :) (prvi primer)

Ok, jeste da validaciju vrsi funkcija forme 'validate' koja se samo poziva u kontroleru,
al moja poenta je bila da se validacija podataka radi pre nego sto se posalju u model,
sto bi onda dovelo na vracanje prvobitne teme "fat model skinny c. vs ..."

U svakom slucaju je bolje koristiti ili jedan ili drugi pristup, mesanje nikako.

Pa ovaj primer je po meni bas obrnuto.

Samo ako zamislimo da forma ne postoji kao koncept i da se validate poziva iz konstruktora modela i ako ne uspe baca exception naprimer (sto je lagani refactoring) - onda cak i eksplicitno pripada modelu a ne kontroleru. Kontroler samo pokusa da napravi model sa POST podacima i javi rezultat.

Ok, hajde ovako ... ako sam ja dobro razumeo vi tvrdite da validacija mora da ide u controlleru? Evo situacije pa da vidimo:

Imam controller "User", koji ima svoj model "User" ... validacija je u controlleru, model prima "sažvakano" i odradi svoje, vrati neki status ili data.

Onda imamo neki conrtroller B, koji ima potrebu da odradi nešto što već imamo urađeno u modelu "User" (na primer da pokupi user record), i logično bi bilo da ne pišemo istu funkciju u modelu B, kada već to imamo u Users modelu, zar ne?

To znači da bi morali da imamo validaciju u controlleru B jer u modelu User nemamo nikakvu validaciju, to opet znači da bi morali copy-paste iz validacije iz controllera Users ... što je po meni dupliran kod.

Ne, samo ja to tvrdim :) tj. ni ne tvrdim nego zelim da prodiskutujemo o tome...

Postoji poseban metod za validaciju 'validate' koji bi trebalo u ovom slucaju pozvati jednom u kontroleru A i drugi put u kontroleru B. Za konkretno tvoj slucaj ta jedna linija nazalost jeste duplirana.

Ako aplikacija raste sve vise(sto se cesto desava), mozes lako imati slucaj gde u kontroleru C treba da pokupis iste te podatke iz modela, ali u postu saljes drugacije parametre nego za prva dva slucaja, onda ostaju opcije:

da u modelu pitas: if(podaci1){validacija1}elseif(podaci2){validacija 2} - meni se ovo ne svidja
Ili mozes naravno napraviti jos jednu metodu u modelu koja ce 80% liciti na prvu - isto dupliran kod.

Dok ako radis validaciju u kontroleru, u svakom pozivas drugaciju metodu
validate1, validate2, validate3, ...
Sa druge strane zasto bi ulazio u model ako mozes i pre ulaska u njega da ustanovis da ni ne treba da ulazis, nego da izbacis gresku ?

__________

U svakom slucaju vidim da je poenta "fat" modela da se sto vise stvari generalizuje, pa da se ubace u njega.

E sad jbg, treba predvideti (biti faca) kod aplikacije cije programiranje traje 1-2god. (i posle nadogradnja ko zna koliko) da ces neku metodu u modelu napraviti tako da ces je koristiti uvek, bez da je menjas jer ako je izmenis mozda zeznes negde nesto gde si je koristio odavno.
Onda se tu desava da je ipak ne menjas, nego da napravis novu koja lici 80% na nju, opet lose, a mogao si samo da smajis njenu veliku lokigu i budes siguran da ces moci da je i posle 2-3god. koristis.

Evo još malo logike i kontra logike :)

Kažeš ima samo 1 metod validate koji zoveš svaki put kada zoveš neku funkciju iz modela, a što onda ne bi taj metod validate pozivao iz te funkcije modela, ako je neophodno da se izvrši uvek pre nego što se pozove ta funkcija?

Da ne pričamo o onim drugim logičnim stvarima da moraš da paziš u svakom kontroleru da si obavezno odradio neki "validate" pre poziva funkcije iz modela.

Da me pričamo o tome da ti u stvari kontrolleru prepuštaš brigu o tipovima podataka, recimo ako šalješ parametar "user_id" da bo pokupio user record, tvoj controller će morati da zna da je to integer, a po meni je normalno da model brine o tipovima podataka i castovanju i validaciji inputa ... i svemu što se tiče samih podataka. IMO (banalizovano): controller je flow, model je data (both I/O).

Ja sam tvrdio apsolitno suprotno - da NE TREBA da bude u kontroleru skoro nikad.

Ajmo malo teorije sistema - svaki sistem ima ulaze i izlaze, a unutar sistema se odvija proces obrade podataka. Tako treba i posmatrati i model i view i controller - kao odvojene sisteme, koji rade zajedno u jednom većem sistemu. A web aplikacija, kao složenin sistem se ne sastoji samo iz MVC-a, već postoje i funkcije, helperi, hookovi, itd. Najbitnije je da svaki podsistem ima dobar API, a u to spadaju i jasno definisana pravila za ulazne parametre kao i rezultat obrade podataka. A između ostalog, dobar sistem je onaj koji vodi računa o svojim ulaznim parametrima.

Model kao sistem ima svoje public metode kojima pristupaš iz drugih sistema. To nisu samo kontroleri, to mogu biti i drugi modeli, može biti view, helper, hook. Znači, totalno zaboravi KO i ODAKLE pristupa modelu i fokusiraj se na implementaciju i kreiranje API-ja, a to znači da olakšaš drugima (ili sebi) korišćenje sistema.

@blues: ako u modelu direktno dohvatas $_POST onda moras da menjas model da bi dohvatio te podatke iz npr. memcache-a ili fajla... mozda ti to i ne treba, ali to je tako minorna razlika u kolicini koda u kontroleru da jednostavno nema opravdanja da taj $_POST ne prosledis kao parametar modelu i tako napravis 50x fleksibilniji kod...

Sto se tice validacije, ja to u svom FW-u radim ovako:

- Kontroler validira podatke koji se ticu njega, tipa provera sessiona, da li je CRLF zastita (token) ispravan, da li je confirm password isti kao passsword, da li je chekirano 'I Agree' i sl. To su podaci koji ne postoje ni u jednom modelu i odnose se samo na taj request i zato nema smisla to stavljati u model. Naravno te sve provere su osnovnoj klasi, a konkretni kontroleri to samo naslede i vecina provera se onda radi automatski... ovo vezano za registraciju se ocigledno radi samo u odgovarajucem kontroleru...

- Model validira sve podatke koji se nalaze u njemu, i to automatski, kod svakog inserta i updejta (koji je resen kao save($_POST) metoda koja sama shvati jel insert ili updejt i koje podatke treba da snimi). Svaki model ima validaciona pravila za sva polja u njemu, i onda poziva staticki Validator klasu, koja je odvojena utiliti klasa i koja radi konkretnu validaciju..

U sustini to je moja logika koju koristim jos negde od 2007, jednostavno sam kroz trial & error dosao do toga kao najboljeg (za lenstine kao ja) pristupa, a koliko vidim i vecina poznatih FW koristi nesto vrlo slicno, tako da stvarno mislim da je to najbolja praksa...

Ok, očigledno ovde postoji veliki nesporazum oko pojma "podaci" i "validacija", ne mislimo na iste stvari. I ne bih stavio modelu da bira da li će da skuplja iz memcache ili iz baze, i naravno da je "da li je štiklirano I agree" stvar kontrole a ne modela.

Mislim da je upotreba $_POST u modelu loša sa aspekta ponovne upotrebljuvosti koda.

Uzmimo recimo primer gde se post koristi u modelu:
i primer gde se prosleđuju parametri:
Prvi metod, koji koristi post, lako možeš upotrebiti iz kontrolera koji prima POST od forme sa očekivanim podatcima.
Međutim, da li možeš prvu metodu koristiti da upišeš podatke koji ne dolaze iz POST forme, recimo iz neke migracije koja uzima podatke iz stare baze i upisuje u novu?
Ili recimo, možda ćeš želeti da metodu addUser() testiraš kroz unit testove, gde ćeš sam prosleđivati podatke u kodu.

Mislim da je ponovna upotrebljivost druge metide daleko veća, za razliku od prve koja je zakucana za POST kontekst.

model zapravo ne bi trebao imati pojma niti gdje je niti zasto je niti odakle sto dobiva niti kud sta sprema. drugim rijecima, on lebdi izmedju controllera i DALa.

primjer, trenutno mi model dobiva podatke s 3 strane: lokalna baza, REST, backup. aplikacija radi na desktopu, web app, mobile web app.
najjednostavnijim se pokazalo imati helper validation klasu koja zna koji model mora dobiti kakve podatke (ponekad cak i XML validation rules fajl). ako podaci ne valjaju - do modela se nikad niti ne dodje.

nimalo mi se ne svidja da model radi ikakve IO stvari pa makar i samo kao validation atribut na property, method, whatever.

po mom misljenju, ako je model dobio 'string umjesto int' ili 'karakter koji nije smio' ili 'whatever - netko prije modela nije dobro odradio svoj posao.

Ja radim isto tako... Model prčka svoje i nema veze sa validacijom... To se radi prije njega...

Ja obično radim validaciju u kontrolerima, a svakako izbegavam da ponavljama kod.

Mislim da je najbolje da sama definicija validacije bude u samim modelima, koji će sami sebe da validirati pre save() metode.

Upravo tako. To je rutinska stvar koja ce se uvek uraditi na insert() i update() i ne vidim zasto bi se to izdvajalo u kontroler kad ce ta jedna te ista provera postojati u svakom kontroleru koji nesto snima?

Naravno, sam proces validacije radi zasebna klasa, model samo pozove odgovarajucu metodu. Sad kad su dodati mix-ins u php to ce biti jos lepse za pravljenje.

ako je uvijek ista provjera, onda da. ali, kako na taj nacin rijesiti slucaj da implementacija kod jednog korisnika trazi npr password od minimalno 6 znakova, a kod drugog 8, bar jedno veliko slovo i bar jedan broj? ili da pocinje/zavrsava s odredjenim stringom, a zelimo da koristi isti model? (recimo, jedan od trenutnih zahtjeva jednog korisnika je da mu sifra proizvoda ima tocno 7 znakova. drugi hoce 9 i to da mu pocinje sa 'xy')

ovo, recimo, pricam iz konteksta .NET gdje je zgodno jednom napraviti dll s modelom i ne pipati ga vise (za razlicite implementacije) iako ni u phpu nije nista sustinski drugacije. slozis model za npr cms i kasnije samo vozis front-end implementacije dio kojih je i neki validation rules mehanizam. model ne pipas.

naravno, ovo sve nema smisla ako reuse nije ozbiljan zahtjev jer je lakse promijeniti model na 2 implementacije nego ceprkati ovako. ali kad se dogadja slucaj od 50 instalacija, puno je ljepse imati jedinstven model i 50 front-endeva nego svakog po 50 (pa jos ne daj boze i verzija baza)

To su dodatne provere koje se onda urade u kontroleru isto kao npr. ono da li je kliknuto I agree. Ali model treba da brine o konzistenciji podataka koji idu u bazu, a to se ne menja ako se ne menjaju tabele (ili ako se drugacije cuvaju podaci onda fajlovi ili sta vec).

Ne kazem ja naravno da mora ovako ili onako, ali meni je zgodnije ovako, jer tako imas manje koda o kom moras da brines...

Nešto se nismo razumelli, ja nisam rekao da $_POST ide direktno u model nego sam rekao da se u modelu vrši validacija ulaznih podataka, bez obzira na poreklo :)

Po meni treba ovako:

A $data može da bude $_POST iz controllera ili bilo koji drugi array iz nekog drugog objekta

a ovo sa 17 parametara funkcije ne bih sada komentarisao osim da je to loša praksa :)