DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > Programiranje
Beach Wedding Dresses - Looking for the Wedding Dress? Here, 1dress.co.uk stunning collection of beach wedding dresses is just what you are looking for.

Programiranje Java, Perl, VB, ASP, .NET, C, C++, Pascal, Delphi Sponzor: VIP izazov 3

Odgovori
 
Alati teme Način prikaza
Staro 27. 01. 2012.   #1
tasmaniski
profesionalac
Professional
 
Datum učlanjenja: 08.11.2010
Poruke: 211
Hvala: 68
78 "Hvala" u 32 poruka
tasmaniski is on a distinguished road
Default 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.
tasmaniski je offline   Odgovorite uz citat
"Hvala" tasmaniski za poruku:
Staro 27. 01. 2012.   #2
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.263 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

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
jablan je offline   Odgovorite uz citat
2 članova zahvaljuje jablan za poruku:
Staro 27. 01. 2012.   #3
ajankovic
Aleksandar Janković
Qualified
 
Avatar ajankovic
 
Datum učlanjenja: 16.10.2010
Lokacija: Bg-Sd
Poruke: 165
Hvala: 70
54 "Hvala" u 36 poruka
ajankovic is on a distinguished road
Default

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.
__________________
ajankovic.com]
ajankovic je offline   Odgovorite uz citat
"Hvala" ajankovic za poruku:
Staro 28. 01. 2012.   #4
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
1.940 "Hvala" u 579 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

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.
ivanhoe je offline   Odgovorite uz citat
"Hvala" ivanhoe za poruku:
Staro 28. 01. 2012.   #5
tasmaniski
profesionalac
Professional
 
Datum učlanjenja: 08.11.2010
Poruke: 211
Hvala: 68
78 "Hvala" u 32 poruka
tasmaniski is on a distinguished road
Default

Hm.. Dakle, vidim da je glavna poenta:

Citat:
Originalno napisao ivanhoe Pogledajte poruku
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
tasmaniski je offline   Odgovorite uz citat
Staro 28. 01. 2012.   #6
tasmaniski
profesionalac
Professional
 
Datum učlanjenja: 08.11.2010
Poruke: 211
Hvala: 68
78 "Hvala" u 32 poruka
tasmaniski is on a distinguished road
Default

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

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.
tasmaniski je offline   Odgovorite uz citat
Staro 29. 01. 2012.   #7
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
1.940 "Hvala" u 579 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

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.
ivanhoe je offline   Odgovorite uz citat
Staro 29. 01. 2012.   #8
xippi
xippster
Master
 
Avatar xippi
 
Datum učlanjenja: 16.06.2005
Lokacija: Beograd
Poruke: 680
Hvala: 102
138 "Hvala" u 84 poruka
xippi će postati "faca" uskoroxippi će postati "faca" uskoro
Default

Citat:
Originalno napisao ivanhoe Pogledajte poruku
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
xippi je offline   Odgovorite uz citat
Staro 29. 01. 2012.   #9
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.263 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

Citat:
Originalno napisao tasmaniski Pogledajte poruku
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.
__________________
blog
jablan je offline   Odgovorite uz citat
"Hvala" jablan za poruku:
Staro 29. 01. 2012.   #10
tasmaniski
profesionalac
Professional
 
Datum učlanjenja: 08.11.2010
Poruke: 211
Hvala: 68
78 "Hvala" u 32 poruka
tasmaniski is on a distinguished road
Default

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.
tasmaniski je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum


Vreme je GMT +2. Trenutno vreme je 23:44.


Blogodak - Domaci blogovi na jednom mestu Caught in a web - web dev blog
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.