-
Programiranje
(
http://www.devprotalk.com/forumdisplay.php?f=23)
| jablan |
29. 01. 2012. 12:48 |
Citat:
Originalno napisao tasmaniski
(Napišite 104763)
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:
Kôd:
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);
}
U nekom drugom hipotetičkom (khm) frejmvorku može glasiti:
Kôd:
def index
date = Time.parse(params[:date])
@events = Event.get_approved(date)
end
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. |
| bluesman |
29. 01. 2012. 15:03 |
Može neko objašnjenje zašto nikako POST u model? Gde vi radite preveru i sanitizaciju podataka iz POST-a, u kontroleru?
|
| jablan |
29. 01. 2012. 15:12 |
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.
|
| tasmaniski |
29. 01. 2012. 15:28 |
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.
|
| tasmaniski |
29. 01. 2012. 15:36 |
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.
|
| djipko |
29. 01. 2012. 16:18 |
Citat:
Originalno napisao tasmaniski
(Napišite 104767)
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.
|
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. |
| tasmaniski |
29. 01. 2012. 16:32 |
Citat:
Originalno napisao djipko
(Napišite 104769)
datum moze biti validan za jedan model a nevalidan za drugi itd.
|
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}
Citat:
Originalno napisao djipko
(Napišite 104769)
Django ima Form klasu koja ja usko vezana sa modelom i vrsi validacije, i model ih moze imati vise ...
|
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). |
| djipko |
29. 01. 2012. 16:46 |
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) :
Kôd:
f = MyModelForm(request['POST'])
f.validate()
if f.is_valid():
MyModel(f).save()
else:
#prijavi gresku
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. |
| tasmaniski |
29. 01. 2012. 16:57 |
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.
|
| djipko |
29. 01. 2012. 17:31 |
Citat:
Originalno napisao tasmaniski
(Napišite 104772)
al moja poenta je bila da se validacija podataka radi pre nego sto se posalju u model
|
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. |
| Vreme je GMT +2. Trenutno vreme je 06:32. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, 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.
