[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

[MacDada]

Pod względem teoretycznym zgadzam z Zyx'em. 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 (IMG:style_emoticons/default/winksmiley.jpg)


EDIT:
W mojej wizji kontrolerów byłoby wiele.
Przykład oklepany - blog (IMG:style_emoticons/default/winksmiley.jpg)

• Kontroler (router) główny rozpoznaje, że użytkownik chce wyświetlić wpis na blogu. Odpala Widok zajmujący się wyświetlaniem wpisu.
• Widok wyświetlania wpisu odpala sobie Kontroler budowania menu. On rozpoznaje jakie menu chcemy wyświetlić (może być kilka rodzajów menu, kilka sposobów jego budowy) i odpala odpowiedni Widok.
• Widok ten pobiera dane z Modelu opisującego wybrany rodzaj menu i go wyświetla.
• Wracamy do Widoku wyświetlania wpisu. Zbudował on sobie i wyświetlił menu, więc pobiera sobie dane z Modelu zawierającego wpisy i wyświetla główną treść.
• Oprócz tego Widok wyświetlający wpis może chcieć wyświetlić reklamy, więc odpala sobie Kontroler reklam. Ten działa podobnie do Kontrolera menu.

Jak widać generalnie działałoby to tak, że Kontroler nadrzędny odpala Widok, który korzysta z podrzędnych Kontrolerów i odpowiedniego Modelu, by zbudować sobie dynamiczną zawartość. Taka jakby hierarchia. Co dziwne, w ten sposób Kontrolerzy nie korzystają z Modelów, bo... nie potrzebują? Nie wiem po co miałyby to robić.

Zalety tego rozwiązania (oprócz samego oddzielenia warstwy prezentacji od treści) widzę dwie:

• aplikację można podzielić na moduły/pluginy. Każdy moduł zbudowany byłby jako MVC. Inne moduły i moduł główny odpalałyby Kontroler modułu, mówiąc mu czego oczekują, a ten by to realizował;
• tak jak pisałem wcześniej, Widoki korzystałyby z Szablonów, więc graficy nie bawią się logiką Widoku, a jedynie dizajnem Szablonu, a co więcej jeden Szablon mógłby być wykorzystany w różnych Widokach.

Ten post edytował MacDada 29.07.2010, 00:44:25