DevProTalk - Fat controller skinny model vs reverse

DevProTalk (http://www.devprotalk.com/index.php)

- Programiranje (http://www.devprotalk.com/forumdisplay.php?f=23)

- - Fat controller skinny model vs reverse (http://www.devprotalk.com/showthread.php?t=10734)

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

Citat:

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

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:

Citat:

Originalno napisao ivanhoe (Napišite 104757)

Kod klasicnog MVC-a ne treba nuzno jedan da bude fat, a drugi skinny, nego treba razdvojiti logiku 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..

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.

PHP kôd:


		
			
class Application_Model_Event extends Zend_Db_Table_Abstract
{  
    function getEvents($date = null){
        $select = $this->select()->from('event')->where('approved = true');
        if($date){
              $select->where('date(start_date) = ?', $date);
        }
         return $this->fetchAll($select);
    }
}

Dok kontroler primi request obrati parametre, odradi upite na bazu koje treba i vrati rezultat u view.

PHP kôd:


		
			
class IndexController extends Zend_Controller_Action {
    public function indexAction() {
           $month = $this->_request->getParam('month');
           $year = $this->_request->getParam('year');
           $day = $this->_request->getParam('day');
           
           // obrade se podaci i kreira ispravan format datuma  $date
           // eventualno se po potrebi pozovu jos neke funkcije i odrade upiti

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

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

Citat:

Originalno napisao ivanhoe (Napišite 104760)

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

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

Citat:

Originalno napisao tasmaniski (Napišite 104759)

Ovako izgleda moj klasican model. Odradi se selekt podataka i vrati rezultat, obicno stavim da se proslede neki parametri, tipa: where, order, limit, itd.

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