Fat controller skinny model vs reverse

[bluesman]

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.

[tasmaniski]

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.

[bluesman]

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

[djipko]

Originalno napisao bluesman

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

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

[salebab]

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.

[ivanhoe]

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

[bluesman]

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.

[Marko Medojevic]

Originalno napisao bluesman

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

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

Uzmimo recimo primer gde se post koristi u modelu:

public function addUser() {
$this->db->insert($_POST['username'], $_POST['password'],$_POST['email']);
}

i primer gde se prosleđuju parametri:

public function addUser($username, $password, $email) {
$this->db->insert($username, $password, $email);
}

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.

[dee]

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.

[mangia]

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