[MVC] Widok nie odwołujący się bezpośrednio do modelu? Opcje

[MacDada]

Hej,

przeczytałem kupę tematów o MVC na forum i zastanawia mnie tu jedna rzecz. Większość osób pokazuje schemat działania aplikacji jako taki:
1.) Kontroler rozpoznaje co użytkownik chce zrobić (np wyświetlić listę użytkowników).
2.) Kontroler odpala wtedy odpowiedni widok.
3.) Widok odpala model.
4.) Model przerabia co tam potrzebuje i zwraca dane do widoku.
5.) Widok prezentuje dane.

Co mnie dziwi to fakt, że w ten sposób jeśli zmienię model, to muszę ingerować też w pliki widoku. Jest on uzależniony od konkretnego modelu. No i widok bezpośrednio współpracuje z modelem, a kontroler pełni funkcję jedynie routera.

Czy w takim razie nie lepszy byłby schemat taki?
1.) Kontroler rozpoznaje co użytkownik chce zrobić (np wyświetlić listę użytkowników).
2.) Kontroler wybiera model i go odpala.
3.) Model przerabia co tam potrzebuje i zwraca dane do kontrolera.
4.) Kontroler wybiera widok i przekazuje mu dane od modelu.
5.) Widok wyświetla dane.

W ten sposób Kontroler rzeczywiście pełni funkcję pośredniczącą między warstwą danych i działań, a warstwą prezentacyjną. Mogę stworzyć różne widoki do reprezentowania tego samego typu danych, a jednocześnie mogę mieć wiele źródeł danych, które będą wyświetlane przez ten sam widok.

Co więcej upraszcza to schemat akcji, który może wyglądać tak:
1.) Kontroler rozpoznaje, co użytkownik chce zrobić (np dodać nowego użytkownika do bazy).
2.) Kontroler wybiera model i go odpala.
3.) Model przerabia co tam potrzebuje i zwraca dane do kontrolera (np kod błędu, kod sukcesu, itd.)
4.) Kontroler wybiera widok i przekazuje mu dane od modelu.
5.) Widok wyświetla dane.

Voila! Okazuje się w ten sposób, że model jest równoważny akcji. Model służy wszystkim operacjom na danych, kontroler służy rozpoznawaniu tego co chce użytkownik i tego co chce model, a widok służy do prezentowania danych przekazanych mu przez kontroler. Co więcej, jeśli widok zwróci błąd, to kontroler znów rozpoznaje co się dzieje i odpala odpowiedni model jako reakcję, np logger. Pure MVC?

Czy może jednak w takim podejściu tkwi jakiś błąd?
pozdr.

Ten post edytował MacDada 27.07.2010, 18:50:34

[Zyx]

Wtedy jeśli zmienisz model, zamiast widoku będziesz musiał modyfikować kontroler (IMG:style_emoticons/default/smile.gif) . Poza tym to już wtedy nie będzie MVC, ale jeden z wzorców pochodnych. W MVP jedno z założeń mówi, że rola modelu i widoku jest zmniejszona na rzecz przypakowanego kontrolera zwanego tam prezenterem, który m.in. pośredniczy w komunikacji. Tyle jeśli chodzi o część teoretyczną, teraz praktyka:

Tak, jak mówisz, robione jest w zdecydowanej większości dostępnych frameworków. I to, czy jest to podejście wygodniejsze czy nie, to już trzeba programistów pytać. Na pewno w części zastosowań lepiej się ono sprawdzi, jednak w innych lepszy będzie MVC. Ja osobiście jestem zwolennikiem trzymania się oryginału bez żadnych udziwnień, ponieważ bardzo często już miałem do czynienia z mocno przerośniętymi kontrolerami, które robiły dosłownie wszystko, tylko nie to, do czego zostały stworzone. Ponadto zapominasz o pewnej rzeczy, jak ustandaryzowany interfejs. Nie wyobrażam sobie sytuacji, by modele nie trzymały się jakiejś konwencji. Dzięki temu niedawno udało mi się zaprojektować... kontroler CRUD ogólnego przeznaczenia oraz zestaw widoków do niego. Może z nim współpracować każdy model, który implementuje odpowiednie interfejsy, przez co de facto napisanie panelu sprowadza się do zrobienia modelu, ponieważ kod kontrolera liczy sobie 7 linijek, z czego 5 to deklaracje klasy, metod i nawiasy klamrowe (IMG:style_emoticons/default/smile.gif) .