|
Programiranje Java, Perl, VB, ASP, .NET, C, C++, Pascal, Delphi Sponzor: |
|
Alati teme | Način prikaza |
27. 01. 2012. | #1 |
profesionalac
Professional
Datum učlanjenja: 08.11.2010
Poruke: 211
Hvala: 68
78 "Hvala" u 32 poruka
|
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. Poslednja izmena od tasmaniski : 27. 01. 2012. u 20:31. |
"Hvala" tasmaniski za poruku: |
27. 01. 2012. | #2 |
VD IT Direktora
Invented the damn thing
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
|
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.
__________________
blog |
2 članova zahvaljuje jablan za poruku: |
27. 01. 2012. | #3 | |
Aleksandar Janković
Qualified
Datum učlanjenja: 16.10.2010
Lokacija: Bg-Sd
Poruke: 165
Hvala: 70
54 "Hvala" u 36 poruka
|
Citat:
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.
__________________
ajankovic.com] |
|
"Hvala" ajankovic za poruku: |
28. 01. 2012. | #4 |
Ivan Dilber
Sir Write-a-Lot
|
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...
__________________
Leadership is the art of getting people to want to do what you know must be done. |
"Hvala" ivanhoe za poruku: |
28. 01. 2012. | #5 | |
profesionalac
Professional
Datum učlanjenja: 08.11.2010
Poruke: 211
Hvala: 68
78 "Hvala" u 32 poruka
|
Hm.. Dakle, vidim da je glavna poenta:
Citat:
|
|
28. 01. 2012. | #6 |
profesionalac
Professional
Datum učlanjenja: 08.11.2010
Poruke: 211
Hvala: 68
78 "Hvala" u 32 poruka
|
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:
PHP kôd:
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 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 ... Poslednja izmena od tasmaniski : 28. 01. 2012. u 19:38. |
29. 01. 2012. | #7 |
Ivan Dilber
Sir Write-a-Lot
|
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...
__________________
Leadership is the art of getting people to want to do what you know must be done. |
29. 01. 2012. | #8 | |
xippster
Master
Datum učlanjenja: 16.06.2005
Lokacija: Beograd
Poruke: 681
Hvala: 102
138 "Hvala" u 84 poruka
|
Citat:
|
|
29. 01. 2012. | #9 |
VD IT Direktora
Invented the damn thing
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
|
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.
__________________
blog |
"Hvala" jablan za poruku: |
29. 01. 2012. | #10 |
profesionalac
Professional
Datum učlanjenja: 08.11.2010
Poruke: 211
Hvala: 68
78 "Hvala" u 32 poruka
|
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 ... Poslednja izmena od tasmaniski : 29. 01. 2012. u 12:30. |
|
|