Temat: Walidacja formularzy po której stronie?

Tomasz Zadora:

Wojciech Soczyński:

[...]

Tomasz niestety uważam, że jesteś w bardzo głębokim błędzie co do twojej interpretacji wzorca MVC. Kontroler w MVC w aplikacji www odpowiedzialny jest za zinterpretowanie żądania HTTP (na podstawie adresu, get, post etc), przekazanie odpowiednich danych do modelu, który zajmuje się ich przetwarzaniem i zwraca nam wynik, który to kontroler przekazuje do widoku w który jest prezentowany użytkownikowi.

Za to ja się obawiam, że tobie myli się struktura z logiką, a w modelu MVC, model to struktura która nie powinna sama siebie zmieniać.

Model może posiadać proste metody zwracające określone dane zależne od jego stanu (np. walidacja formularza - ale to imo zły pomysł), jednak nie powinien swojego stanu tymi metodami zmieniać.

Stan modelu zmienia tylko i wyłącznie kontroler (czyli algorytm/logika), co zresztą pośrednio swoją wypowiedzią potwierdziłeś: to kontroler interpretuje request i w zależności od parametrów requestu podejmuje odpowiednie działania.

Tymczasem w całości zgodnie z Twoim tokiem rozumowania, "rozmywasz" logikę na model i kontroler co niestety nieuchronnie prowadzi do tego, że kodem się gorzej zarządza, pisząc kolokwialnie: gorzej się go ogarnia.

Nie ma czegoś takiego jak "model formularza".

Tutaj myli Ci się widok ze strukturą :)

Owszem jest "model formularza" - to struktura określająca listę pól formularza i ich właściwości.

Jeżeli chodzi o prezentację to kontroler wybiera Viewera który dostaje określony model formularza (który może być zmodyfikowany przez kontrolera) i dokonuje prezentacji.

To tyle, wydaje mi się, że dość dokładnie to wyjaśniłem.

Jeżeli ktoś uważa, że jestem w błędzie / nie podoba mu się to / etc. - jak najbardziej ma prawo :) U mnie taki podział znakomicie działa.

Będę z tobą polemizował. Oczywiście nie zamierzam Cie przekonywać do mojego punktu widzenia, natomiast chciałbym sprostować twoje spojrzenie na moją wypowiedź.

1. "Myli Ci się struktura z logiką" - Moja "interpretacja" MVC jest taka: Akcja kontrolera jest odpowiednikiem eventu np "onClick" na buttonie w aplikacji desktopowej.Do akcji zostają przekazane parametry zdarzenia (u nas request). Jako, że kliknięcie na przycisku ma wywołać określony efekt w innym miejscu aplikacji (u nas wyświetlenie widoku), musi zostać podjęte działanie którego efektem będą jakieś dane - do wyświetlenia, te dane brane są z modelu.

Dla jasności dalej desktopowy przykład:
Mamy DataGrid z kilkalnym nagłówkiem kolumny, po kliknięciu ma nastąpić sortowanie. Nagłówek został kliknięty, zostaje wywołany event. Event przekazuje do modelu prośbę o dane posortowane po polu "X", model wykonuję prośbę i zwraca dane do eventu a event zmienia zawartość DataGrida.

Może wg. Ciebie występuje tu jakieś rozmycie, ale zauważ że:
gdybyśmy owe sortowanie, które wykonuje model przeprowadzali w samym evencie (kontrolerze), to w innym miejscu systemu, chcąc mieć posortowane dane (np. dla tabelki w pdfie), musielibyśmy skopiować cały kod z eventu dla tabeli jakiemuś innemu komponentowi.

Dzięki temu, że ten proces dzieje się w modelu, możemy go zastosować w wielu miejscach, bez copy-paste'a czyli zachowujemy zasadę "DRY".

To jest trywialny przykład, natomiast obrazuje bardzo dobrze rozdzielenie tych trzech warsw - prezentacji (DataGrid), kontrolera (event) i modelu (logika i algorytm sortowania).

Wg. mnie, w MVC kontroler i widok są warstwami infrastruktury, których zadaniem jest umożliwienie korzystania z modelu.

W razie wątpliwości odsyłam do wikipedii -> http://pl.wikipedia.org/wiki/Model-View-Controller

2. Model formularza - jeżeli mówimy o liście pól w formularzu - jego strukturze to ja bym nazwał to raczej specyfikacją niż modelem.Wojciech Soczyński edytował(a) ten post dnia 07.02.11 o godzinie 18:41

Temat: Walidacja formularzy po której stronie?

Wojciech Soczyński:

[...]

Event przekazuje do modelu prośbę o dane posortowane po polu "X", model wykonuję prośbę i zwraca dane do eventu a event zmienia zawartość DataGrida.

To jest (może być) zgodne z tym co pisałem, jeżeli w tym przypadku model nie zmienia swoich właściwości tylko zwraca Tobie listę odpowiednio posortowaną -
czyli mając listę pól dokonuje sortowania i zwraca wynik ale w samym sobie zostawia tak jak było przed sortowaniem.

Jeżeli w wyniku tego zmienia się kolejność pól w samym modelu -
wtedy powinno to być w kontrolerze który reaguje na event.

Czyli:

$model->getSorted() ok
$model->sortIt() bad

Może wg. Ciebie występuje tu jakieś rozmycie, ale zauważ że:
gdybyśmy owe sortowanie, które wykonuje model przeprowadzali w samym evencie (kontrolerze), to w innym miejscu systemu, chcąc mieć posortowane dane (np. dla tabelki w pdfie), musielibyśmy skopiować cały kod z eventu dla tabeli jakiemuś innemu komponentowi.

Jeżeli nie mamy dostępu do $Controller, zawsze można zastosować metodę statyczną w kontrolerze, wywoływaną tak:

Controller::sortIt($model)

ale wtedy powinno to tak działać, że w samym modelu zmienia się
kolejność pól, jeżeli ta metoda jedynie zwraca odpowiednią kolejność
a w modelu jest zachowana stara, to wtedy patrz wyżej: powinno to być w modelu.

Jeszcze taki przykład: gdybyś miał model samochodu i chciał zrobić tak:

$ModelSamochodu->zatankuj($iloscPaliwa);

To już imho jest błąd, bo tankowanie zmienia właściwości samochodu, powinno być:

$KontrolerStacjiPaliw->zatankuj($ModelSamochodu, $iloscPaliwa);

Natomiast:
$Samochod->podajSrednieZuzucieOponWSrody();

jest ok bo nic w samochodzie nie zmienia.

Oczywiście może być $ModelStacjiPaliw ale on nie jest od tankowania, tylko
np. od:

$ModelStacjiPaliw->ktoryPracownikSieNajbardziejLeni();

czyli:

$ModelStacjiPaliw = new ModelStacjiPaliw();
$KontrolerStacjiPaliw = new $KontrolerStacjiPaliw($ModelStacjiPaliw);

$KontrolerStacjiPaliw->zwolnijPracownika($ModelStacjiPaliw->ktoryPracownikSieNajbardziejLeni());

lub

$KontrolerStacjiPaliw->zwolnijNajbardziejLeniwegoPracownika();

Reasumując, wydaje mi się że podobnie postrzegamy MVC - trzeba było to sobie tylko wyjaśnić.Tomasz Zadora edytował(a) ten post dnia 07.02.11 o godzinie 19:14

Temat: Walidacja formularzy po której stronie?

Przemysław R.:
Tak jak w temacie która strona klient czy serwer jest lepsza do walidowania danych z formularza?

Głównie po stronie serwera. Jak user namiesza w kodzie np. wtyczkami do FF to będziesz miał cieplutko :>.

Temat: Walidacja formularzy po której stronie?

Tomasz Zadora:

Jeszcze taki przykład: gdybyś miał model samochodu i chciał zrobić tak:

$ModelSamochodu->zatankuj($iloscPaliwa);

To już imho jest błąd, bo tankowanie zmienia właściwości samochodu, powinno być:

$KontrolerStacjiPaliw->zatankuj($ModelSamochodu, $iloscPaliwa);

IMHO to co tutaj opowiadasz to podejscie proceduralne a nie obiektowe... ale nie bede offtopowal zabardzo :)

co do samej walidacji/formularzy to dorzuce do dyskusji:
http://weierophinney.net/matthew/archives/200-Using-Ze...

Ciekawe podejscie jednego z contributorow Zenda za które to oczywiście został odpowiednio zjechany :)
Polecam lekture bo facet zaprezentowal podejscie malo popularne wsrod developerow ale IMHO bardzo wygodne i poprawne...

Temat: Walidacja formularzy po której stronie?

Maciek Marczuk:

[...]

IMHO to co tutaj opowiadasz to podejscie proceduralne a nie obiektowe... ale nie bede offtopowal zabardzo :)

Proceduralne to by było gdyby nie było obiektów.

Metody używane w obiektach to procedury, tyle że "otoczone" (enkapsulacja) obiektem i dlatego są metodami a nie procedurami.

Temat: Walidacja formularzy po której stronie?

Tomasz Zadora:

Maciek Marczuk:

[...]

IMHO to co tutaj opowiadasz to podejscie proceduralne a nie obiektowe... ale nie bede offtopowal zabardzo :)

Proceduralne to by było gdyby nie było obiektów.

Mialo byc bez offtopa :)

hmmm
to ze kierowca autobusu siada za kierownica rajdowki czyni go automatycznie kierowca rajdowym?

Temat: Walidacja formularzy po której stronie?

Przemysław R.:
Tak jak w temacie która strona klient czy serwer jest lepsza do walidowania danych z formularza?

bez dwoch zdan, po obu stronach - UI + bezpieczenstwo

Temat: Walidacja formularzy po której stronie?

Arkadiusz K.:
bez dwoch zdan, po obu stronach - UI + bezpieczenstwo

Bardzo ładne podsumowanie. Walidacja po stronie klienta to przeważnie taki "użyteczny" lukier.

Temat: Walidacja formularzy po której stronie?

Maciek Marczuk:

[...]

Mialo byc bez offtopa :)

Trzeba było go nie zaczynać :)

hmmm
to ze kierowca autobusu siada za kierownica rajdowki czyni go automatycznie kierowca rajdowym?

Zły przykład. Kojarzysz może taki język jak Basic na 8-bitowcach ? Nie wiem jak się tam nazywał styl programowania ale to był koszmar.

Następnie przyszło właśnie programowanie proceduralne - czyli funkcje, a po nich mamy programowanie obiektowe.

Do tego dodam:

http://wiki.answers.com/Q/What_is_the_difference_betwe...

Nie rozumiem w takim razie dlaczego np. to:

$KontrolerStacjiPaliw->zatankuj($ModelSamochodu, $iloscPaliwa);

jest wg. Ciebie procedurą, to jedna, abstrakcyjna metoda na zatankowanie abstrakcyjnego samochodu abstrakcyjną ilością paliwa przez abstrakcyjnego kontrolera stacji paliw.Tomasz Zadora edytował(a) ten post dnia 07.02.11 o godzinie 21:02

Temat: Walidacja formularzy po której stronie?

Tomasz Zadora:

Maciek Marczuk:

[...]

IMHO to co tutaj opowiadasz to podejscie proceduralne a nie obiektowe... ale nie bede offtopowal zabardzo :)

Proceduralne to by było gdyby nie było obiektów.

Metody używane w obiektach to procedury, tyle że "otoczone" (enkapsulacja) obiektem i dlatego są metodami a nie procedurami.

To że używamy obiektów to nie znaczy automatycznie, że piszemy obiektowo. Obiekt to dane plus metody i to nie gettery i settery. Tylko konkretne zachowania. Obiekt nigdy nie ujawnia i nie pokazuje swojego wewnętrznego stanu. W twoim przykładzie wg. mnie są dwa błędy. Pierwszy to taki, że traktujesz stację benzynową jako kontroler a tak naprawdę ona nim nie jest. Każdy z elementów tej układanki jest modelem, a dokładnie encją (w sensie DDD). Gdybym miał to wymodelować zrobiłbym tak:

class Samochód {

    function przyjmijPaliwo(Benzyna $paliwo);

    function stanBaku();

    function pojemnoscBaku();

}



class Dystrybutor {

    function pobierzPaliwo($typ, Litr $ilosc);

}



class Kierowca {

    function zatankuj(Samochod $samochod, Dystrybutor $dystrybutor){

         $iloscPaliwa = $samochod->pojemnoscBaku() - $samochod->stanBaku();

         $paliwo = $dystrybutor->pobierzPaliwo('Benzyna', new Litr($iloscPaliwa));

         $samochod->przyjmijPaliwo($paliwo);

    }

}

Tak właśnie wg. mnie wyglądałby model. Natomiast kontroler to była by techniczna strona tylko, jeżeli by to była klasyczna strona www, to przyjął by dane z jakiegoś formularza, stworzył bądź pobrał obiekty ww. klas i przeprowadził odpowiednie operacje.

Alternatywnie, nasz kontroler mógłby być webservice'em i wtedy by przyjął dane jako SOAP albo JSON albo coś innego.

Enkapsulacja i abstrakcja wymaga, by obiekt był reprezentowany tylko przez swój zewnętrzny interfejs a nie przez wewnętrzny stan. Dlatego obiektu nie powinno prosić się o dane do wykonania operacji tylko o wykonanie operacji.Wojciech Soczyński edytował(a) ten post dnia 07.02.11 o godzinie 21:17

Temat: Walidacja formularzy po której stronie?

Tomasz Zadora:

Maciek Marczuk:

[...]

Mialo byc bez offtopa :)

Trzeba było go nie zaczynać :)

hmmm
to ze kierowca autobusu siada za kierownica rajdowki czyni go automatycznie kierowca rajdowym?

Zły przykład. Kojarzysz może taki język jak Basic na 8-bitowcach ? Nie wiem jak się tam nazywał styl programowania ale to był koszmar.

Następnie przyszło właśnie programowanie proceduralne - czyli funkcje, a po nich mamy programowanie obiektowe.

Do tego dodam:

http://wiki.answers.com/Q/What_is_the_difference_betwe...

okok
historie informatyki kazdy w jakims tam stopniu ogarnia :)

piszac proceduralnie mialem na mysli raczej tok myslenia a nie skladnie jezykowa...

Temat: Walidacja formularzy po której stronie?

Maciek Marczuk:

Tomasz Zadora:

Maciek Marczuk:

[...]

Mialo byc bez offtopa :)

Trzeba było go nie zaczynać :)

hmmm
to ze kierowca autobusu siada za kierownica rajdowki czyni go automatycznie kierowca rajdowym?

Zły przykład. Kojarzysz może taki język jak Basic na 8-bitowcach ? Nie wiem jak się tam nazywał styl programowania ale to był koszmar.

Następnie przyszło właśnie programowanie proceduralne - czyli funkcje, a po nich mamy programowanie obiektowe.

Do tego dodam:

http://wiki.answers.com/Q/What_is_the_difference_betwe...

okok
historie informatyki kazdy w jakims tam stopniu ogarnia :)

piszac proceduralnie mialem na mysli raczej tok myslenia a nie skladnie jezykowa...

Racja, programowanie obiektowe i proceduralne to filozofie, nie techniki.
To "kiedyś były funkcje i nazywały się procedury a teraz są obiekty i funkcje nazywają się metody" to tak jak powiedzieć:
człowiek to taka małpa co mieszka w mieście i co sobotę idzie na piwo z kolegami ;)...

Temat: Walidacja formularzy po której stronie?

Jeżeli ktoś się na blogu zastanawia w przepastnym wpisie gdzie umieścić metodę to chyba coś nie tak ?

Wystarczy zastosować prostą zasadę i tego typu dylematy rozwiązuje w kilka sekund w prosty sposób:

Jeżeli działam w MVC i tworzę metodę która działa na modelu to odpowiadam sobie na proste pytanie:

Czy metoda w wyniku swojego działania zmieni lub może zmienić model ?

TAK - umieścić w kontrolerze
NIE - można umieścić w modelu

I koniec, zastanawianie się przez długie godziny i pisanie artykułów zostawiam innym ;-)

Stosuje ten wzorzec od ponad 6 lat, jest rewelacyjny.

I tym pozytywnym akcentem kończę tą dyskusję i pozdrawiam Panowie, możecie sobie nawzajem jeszcze porozdawać kilka plusów :)

Temat: Walidacja formularzy po której stronie?

I koniec, zastanawianie się przez długie godziny i pisanie artykułów zostawiam innym ;-)

>
moze to i lepiej :)

Stosuje ten wzorzec od ponad 6 lat, jest rewelacyjny.

I tym pozytywnym akcentem kończę tą dyskusję i pozdrawiam Panowie, możecie sobie nawzajem jeszcze porozdawać kilka plusów :)

Cieszy mnie to ze jestes z siebie zadowolony :)
ja tam swojego kodu sprzed 6 lat bym kijem nie dotknal...

Nie probuje Cie nawrocic tylko wiem ze zagladaja tu rozni ludzie, czesto poczatkujacy, i fajnie jakby wiedzieli ze sa inne rozwiazania niz te ktore dla Ciebie sa rewelacyjne...

Temat: Walidacja formularzy po której stronie?

Tomasz Zadora:
Jeżeli ktoś się na blogu zastanawia w przepastnym wpisie gdzie umieścić metodę to chyba coś nie tak ?

Wystarczy zastosować prostą zasadę i tego typu dylematy rozwiązuje w kilka sekund w prosty sposób:

Jeżeli działam w MVC i tworzę metodę która działa na modelu to odpowiadam sobie na proste pytanie:

Czy metoda w wyniku swojego działania zmieni lub może zmienić model ?

TAK - umieścić w kontrolerze
NIE - można umieścić w modelu

I koniec, zastanawianie się przez długie godziny i pisanie artykułów zostawiam innym ;-)

Stosuje ten wzorzec od ponad 6 lat, jest rewelacyjny.

I tym pozytywnym akcentem kończę tą dyskusję i pozdrawiam Panowie, możecie sobie nawzajem jeszcze porozdawać kilka plusów :)

Ja również dziękuje za ciekawą dyskusję i mam nadzieję, że ktoś kreatywnie skorzysta z tych różnych wniosków, które się przy okazji wykluły ;)

Temat: Walidacja formularzy po której stronie?

Tomasz Zadora:
Jestem zdania, że jeżeli chodzi o MVC to powinien to robić kontroler.

Model to struktura, kontroler to logika która przekształca model, sprawdza, etc.

hm... polemika:
- kontroler steruje aplikacją nie nie ma nic wspólnego z domeną
- model odpowiada za to co przetwarzane w 100%
- widoki tylko przechwytuję akcje użytkownika i zwracają wyniki działania obiektów modelu

jeżeli jakąkolwiek logikę dziedziny (w tym walidację) umieścimy w widoku to każda sytuacja posiadania inteligentnych skórek (osobno na komputer, osobno na telefon, osobno, na smartfony itp.) doprowadzi do powielania reguł biznesowych (walidacji) i stracimy podstawową korzyść: jednoosobowa (punktowa) odpowiedzialność.

nie rozumiem dlaczego kontroler miałby ingerować w model.

Co do samej bazy danych (SQL) - tutaj już mamy *model tabeli sql* następnie, podobnie mamy *kontroler tabeli sql* który przeprowadza insert/update i zanim operację SQL przeprowadzi sprawdza *na niższym poziomie* dziedzinę danych - czyli jeżeli mamy pole SQL numeryczne to czy faktycznie wartość jest numeryczna, etc.

a cóż to takiego? baza w MVC to powinna być wyłącznie implementacja utrwalania.

Temat: Walidacja formularzy po której stronie?

Przemysław R.:
właśnie doszliśmy do kwestii gdzie trzymać mechanizm walidacji - kontroler czy model?

Model, poprawność nazwiska powinien kontrolować wyłącznie obiekt który nosi to nazwisko i żaden inny.

uwazam, że w zasadzie poprawnie używany framework MVC (nie licząc jakiejś tam oczywistej kosmetyki) powinien dać gotowe oprogramowanie wyłącznie po zbudowaniu specyficznego dla problemu modelu dziedziny.

Temat: Walidacja formularzy po której stronie?

Tomasz Zadora:
w modelu MVC, model to struktura która nie powinna sama siebie zmieniać.

skąd ta teza?

Model może posiadać proste metody zwracające określone dane zależne od jego stanu (np. walidacja formularza - ale to imo zły pomysł), jednak nie powinien swojego stanu tymi metodami zmieniać.

wtedy nazywa się Anemiczny Model Dziedziny i jest dokładnie antywzorcem:

Anemiczny model dziedziny (ang. Anemic Domain Model): Antywzorzec opisany przez Martina Fowlera. W tym przypadku model dziedziny składa się z klas z atrybutami bez metod, nie jest więc obiektowy. Logika biznesowa przeniesiona jest do innych klas, które transformują klasy dziedziny zmieniając ich stan (stąd nazwa Fowlera: skrypty transakcyjne). Antywzorzec ten przedmiotem wielu dyskusji - znaczna część metodyk tworzenia oprogramowania w Javie (w tym EJB) operuje na takim modelu. Duża część projektantów przenosi też swoje przyzwyczajenia z modelowania baz danych modelując system w ten sposób.

http://pl.wikipedia.org/wiki/Antywzorzec_projektowy

Stan modelu zmienia tylko i wyłącznie kontroler (czyli algorytm/logika), co zresztą pośrednio swoją wypowiedzią potwierdziłeś: to kontroler interpretuje request i w zależności od parametrów requestu podejmuje odpowiednie działania.

Logika biznesowa to Model

Jeżeli ktoś uważa, że jestem w błędzie / nie podoba mu się to / etc. - jak najbardziej ma prawo :) U mnie taki podział znakomicie działa.

aplikacje bez błędów w Pascalu tez działką ale to niczego nie dowodzi... zastanów się w ilu miejscach implementujesz to jak Kowalski ma na nazwisko....Jarek Żeliński edytował(a) ten post dnia 08.02.11 o godzinie 14:15

Temat: Walidacja formularzy po której stronie?

Tomasz Zadora:

Maciek Marczuk:

[...]

IMHO to co tutaj opowiadasz to podejscie proceduralne a nie obiektowe... ale nie bede offtopowal zabardzo :)

Proceduralne to by było gdyby nie było obiektów.

Metody używane w obiektach to procedury, tyle że "otoczone" (enkapsulacja) obiektem i dlatego są metodami a nie procedurami.

stosowanie obiektowych narzędzi nie jest tożsame z tworzenie obiektowego oprogramowania :)

Temat: Walidacja formularzy po której stronie?

Jarek Żeliński:

[...]

jeżeli jakąkolwiek logikę dziedziny (w tym walidację) umieścimy w widoku to każda sytuacja posiadania inteligentnych skórek (osobno na komputer, osobno na telefon, osobno, na smartfony itp.) doprowadzi do powielania reguł biznesowych (walidacji) i stracimy podstawową korzyść: jednoosobowa (punktowa) odpowiedzialność.

Nie nie pisałem o umieszczaniu logiki w viewerze, rozumiem więc, że to Twoja taka poboczna dygresja ?

wtedy nazywa się Anemiczny Model Dziedziny i jest dokładnie antywzorcem:

Pomyłka, założenie jest takie, że model może posiadać metody ale tylko takie które nie zmieniają jego stanu.

http://pl.wikipedia.org/wiki/Model-View-Controller#Pas...

" Żądanie zmiany stanu i wykonania jakichś operacji pochodzi zawsze z kontrolera oraz z widoku za pośrednictwem udostępnionego API"

Z tą poprawką (u mnie), że widok nie ma prawa tego robić.

Logika biznesowa to Model

Kto tak napisał i dlaczego miało by to być wiążące ? Ok powiedzmy, że to prawda, w takim razie kontroler nie jest logiką ? :D

Metody używane w obiektach to procedury, tyle że "otoczone" (enkapsulacja) > obiektem i dlatego są metodami a nie procedurami.

Proponuję przeczytać artykuł anglojęzyczny do którego dałem link wcześniej, może wtedy będzie wiadomo o co mi chodziło.

Naprawdę proszę już nie pisać polemik bo to nie ma sensu.