Komentarze do: (V)iew, przygłupi kolega każdego MC

Autor: MacDada

MacDada — Thu, 29 Jul 2010 00:07:58 +0000

W sumie to co wyżej plus szczegóły pomysłu MVTC umieściłem na blogu:
http://chaotycznie.pl/programowanie/mvtc-czyli-moj-pomysl-na-wzorzec-projektowy/

Autor: MacDada

MacDada — Wed, 28 Jul 2010 22:48:51 +0000

Sam jak dotąd widziałem rolę Kontrolera jako właśnie takiego pośrednika między Modelem a Widokiem; czyli Kontroler rozpoznaje co ma się dziać, odpala odpowiedni model, pobiera i interpretuje dane z modelu, na podstawie tego odpala odpowiedni widok, do którego przekazuje dane.

Na forum.php.pl Zyx ujął MVC w inny sposób, który także prezentuje tutaj. Pod względem teoretycznym się z nim zgadzam. Wystarczy spojrzeć na diagram MVC na Wikipedii i wyraźnie widać, że Widok także może mieć bezpośredni dostęp do modelu.

Stąd doszedłem do wniosku, że w praktyce zamiast MVC lepiej zrobić MVTC, czyli Model View Template Controller. W ten sposób mamy Kontroler, który odpala model i odpowiedni widok, widok odpala sobie w razie potrzeby model, a na koniec zbiera to co chce do kupy i przekazuje do Szablonu. W ten sposób wilk syty i owca cała, tzn Graficy bawią się jedynie na Szablonie, a jednocześnie Widok nie jest tylko Szablonem, ale zawiera także logikę Widoku w postaci paginatora, itp.

Choć na razie to czysta teoria, bo takiego podejścia nie wypróbowałem i nie widziałem ;)

Autor: anen

anen — Mon, 24 May 2010 21:37:55 +0000

Ja tam uważam , że poprostu był pijany :) Informatycy Warszawcy mają dobre głowy skoro u nich idzie na uczelni kupić PIWO i Vodke :)

Autor: Damian Tylczyński

Damian Tylczyński — Mon, 24 May 2010 21:06:25 +0000

@anen, Twój gość z Holandii poszedł trochę za daleko i próbuje porównywać paradygmaty porównując konkretne ich implementacje, nie same idee. Porównywał magię klasycznego ASP.NET w którym WebFormsy załatwiały za Ciebie niemal wszystko, a ASP.NET MVC w którym nie możesz być wykliko-sobie-mychą-programistą. A jest to związane tylko z implementacją tych dwóch frameworków, z trudnością obsługi. Nie uwarunkowaniem wzorców czy paradygmatów. ASP.NET też mógł wykorzystać wzorzec MVC, powiązanie zdarzeń z akcjami nie jest chyba jakimś wielkim problemem. Jednak Microsoft postanowił skopiować pierwszy lepszy framework istniejący już w sieci.

Autor: anen

anen — Sun, 23 May 2010 22:08:22 +0000

Wógle sama idea trzymania się wzorca projektowego jest ciężka do pojęcia dla naszego mózgu :) Miałem przyjemność w lutym rozmawiać z gościem co tworzył ASP.NET MVC – koleś z holandi , od xx lat ma MVP ( tak wiem Microsoft – pojedzie po mnie ) ale to co on mi mówił – You have got Web Forms and MVC, normal person knows that where’s action there’s reaction but in MVC you get POST and GET (WTF).
Prawda jest taka , php czy asp.net czy cokolwiek innego – nie zawsze MVC załatwia sprawę , a co bardziej MVVM , czasami liczy dobry projekt – wzorzec jest jako pomoc – nie wymóg( no chyba że specyfikacja mówi inaczej )

Autor: thek

thek — Fri, 21 May 2010 08:57:03 +0000

A ja poprę i autora i Zyx’a. Na forum php.pl także miałem post w dyskusji o wzorcu MVC i dla mnie powinien on dzialać jak dwukierunkowy trójkąt. Każdy z elementów powinien umieć się komunikować w pozostałymi. To, że we frameworkach wszystko idzie przez kontroler to pewien standard, który można jednak we własnych projektach sobie odpuścić. Jak dla mnie to o czym mówiono, czyli widok ma swój szablon jest dobrze widoczne we wszelkiego rodzaju stronach w sposób niejawny. To odwołania AJAXowe i ogólnie JS (jQuery m.inn.). Widok wyświetla pewien szablon, ale jego logiką kieruje JS. Odpowiada za choćby paginację czy tego typu elementy. Wtedy dzialanie wygląda tak:
1. Wyświetl szablon strony ( szablon widoku )
2. Pobierz domyślne ustawienia AJAX ( logika widoku )
3. Pobierz dane i zwróć je ( model )
4. Wypełnij szablon ( szablon widoku )
Wszelkie zmiany na stronie to tylko zmiana logiki ( ustawień parametrów domyślnych czy tymczasowych ) widoku. Można więc powiedzieć, że programiści implementują funkcjonalność Widok Model ale na poziomie tworzenia kolejnego obiektu, którym jest obiekt AJAX, który też musi mieć swoje struktury wzorca MVC (M i C, bo tutaj akurat V jest zazwyczaj zbędny).

Autor: sokzzuka

sokzzuka — Tue, 04 May 2010 06:58:17 +0000

Moim zdaniem front controller powinien na podstawie danych z requestu pobierać dane od modeli i wpychać je do odpowiedniego widoku, logika biznesowa powinna być w modelu.

Moim zdaniem widok raczej powinien dostawać dane niż prosić o nie…

Autor: matipl

matipl — Fri, 30 Apr 2010 10:12:14 +0000

@bigZbig: dokładnie, aby widok był widokiem, pobranie danych i cała obróbka musi mieć miejsce gdzieś indziej (kontrol, helper widoku etc).
Bo należy pamiętać, że widokami zajmują się frontendowcy, którzy potrafią usunąć wywołanie danej metody, a nie mówiąc co by było gdyby była tam większa logika.

Autor: bigZbig

bigZbig — Thu, 29 Apr 2010 14:05:05 +0000

Mam takiego kolegę, który używa kontrolerów (w Kohana PHP Framework) tylko po to aby pobrać dane i wrzucić je do widoku – równie dobrze mógłby przekazać do widoku obiekt modelu i kazać webdevowi samemu pobrać sobie wymagane dane i dopowiednio je przekształcić. Tak czy inaczej gdzieś musi być miejsce na tzw. obróbkę danych. Kiedyś pracowałem w Urzędzie Miasta – tam to się nazywało sporem kompetencyjnym. Damian dodatkowo poruszył problem pt. “kto się ma tym zająć” – z tego co pamiętam to nazywaliśmy to spychologią.

No ok ale nie o to chyba chodzi Zyxowi czy Damianowi? Oni proponują odwrócenie flow. Z tego co zrozumiałem Zyxs proponuje aby frontend kontroler zamiast wywoływać kontroler “lokalny” który decydyje jakie dane pobrać i jakiemu widokowi je przekazać do wyświetlenia, wywoływał od razu widok (nazwijmy go świadomym), który pobierałby sobie niezbędne dane i w razie potrzeby użył dostępnych narzędzi do ich obróbki. Takim narzędziem byłby np. paginator, czy też komponent renderujący listę lub formularz. A ja się pytam czy taki widok byłby w takim razie dalej widokiem?

Wracając do mojego kolegi. Jemu też się nie chciało wstępnie preparować danych np. generować url-i, obliczać cen brutto itp. A potem i tak dostawał na twarz te zadania tyle, że robił je w widoku zamiast w kontrolerze bo webdev jest od przesuwania boksów od 2 piksele do góry lub na dół a nie od martwienia się o to czy zbudował w widoku działające urle i czy cena brutto wyliczana jest poprawnie.

Autor: Damian Tylczyński

Damian Tylczyński — Tue, 27 Apr 2010 17:06:22 +0000

@matipl, i na tym EOT też jak najbardziej z mojej strony, bo rozmawiamy o 4 różnych światach. Albo 5 światach. 6 światach? No bo… ja wiem… ale nie powiem.