[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

[zelu]

Od razu mówię, że nie mam jakiegoś strasznie dużego doświadczenia we frameworkach, ale wydaje mi się, że drugie podejście (wszystko przechodzi przez kontroler) jest sensowniejsze i bardziej intuicyjne. Piszesz Zyx, że w drugim podejściu kontroler robi wiele rzeczy, których nie powinien. A co, kiedy w pierwszym schemacie (typowy MVC) widok pobiera dane z Modelu i okazuje się, że Model zwrócił kod błędu. Teraz to widok zaczyna robić zbyt wiele zbędnych rzeczy, ponieważ musi sprawdzać kod błędu i zawiera w sobie niepotrzebne instrukcje if, przez co traci na przejrzystości kodu. A w podejściu drugim wywołujemy model i mamy prosty zestaw instrukcji warunkowych z renderowaniem widoków. Przejrzystość kodu znacznie na tym zyskuje.
A dodatkowo co z sytuacją o której pisał MacDada: zwracanie różnych typów widoków (HTML, JSON, XML). Wtedy tylko raz tworzymy odwołanie do danego modelu i ponownie dzięki kilku prostym instrukcjom if wyświetlamy odpowiedni widok.

Oczywiście tak jak powiedziałem, nie mam dużego doświadczenia we frameworkach, dlatego byłbym wdzięczny za ewentualne skorygowanie mojego myślenia (IMG:style_emoticons/default/winksmiley.jpg)


Pozdrawiam