[MVC] Kontroler - gdzie? Opcje

[Kikert]

Witam,
uprzedzam, że przeczytałem temat przypięty wraz z odnośnikami i niewiele mi to pomogło - niestety.

Mam trzy pytania odnośnie tego wzorca - jeżeli tworzę aplikację web'ową, to:
1. Czy kontroler jest samym plikiem (index.php), czy dopiero plik główny go inicjuje?
2. Jak jest z widokiem? Czy HTML jest zwracany do kontrolera, czy do pliku głównego? (przy opcji, że kontroler trzeba wcześniej załączyć)
3. Czy widok jest załączany przez kontroler, czy przez plik główny? (również przy drugiej opcji)

[marcio]

Nie lubię takich trochę personalnych docinków, ale... nie ma to jak uargumentowana opinia. Poza tym to nie jest wizja Zyxa, tylko założenia tego wzorca (który nie był tworzony z myślą o "środowisku webowym", w którym to ten wzorzec najczęściej jest skopany).

A gdzie tak jest napisane ze jest dobrze jak to on mowi na wiki na temat MVC pisza inaczej chyba ze mam problemy z czytaniem.

[-=Peter=-]

A gdzie tak jest napisane ze jest dobrze jak to on mowi na wiki na temat MVC pisza inaczej chyba ze mam problemy z czytaniem.

Chyba masz problemy z czytaniem: http://en.wikipedia.org/wiki/MVC_Pattern#Overview
A konkretniej zdanie "A view queries the model in order to generate an appropriate user interface".

Osobną kwestią jest to, że wikipedia to nie zbyt wiarygodne źródło, zwłaszcza jeśli chodzi o takie informacje.

Prosty przykład w MVC jaki serwuje ZF, symfony i inne frameworki:
Chcemy pobrać stronicowaną listę elementów modelu, w kontrolerze (lub też w modelu) tworzymy obiekt paginatora, mówimy mu aby pobrał takie i takie elementy. Kontroler przekazuje paginator do widoku, który wyświetla to co w nim jest.

Konsekwencje: kontroler miesza się w warstwę prezentacji, bo to widok na podstawie modelu powinien decydować o tym czy dane są stronicowane i co ile. Chcemy zmienić liczbę wyświetlanych elementów lub wyłączyć stronicowanie, paradoksalnie musimy edytować kontroler - widok i kontroler wcale nie są niezależne.

W implementacji podanej przez @Zyxa to inaczej wygląda, w widoku (na podstawie danych zawartych w modelu) zachodzi decyzja czy dana lista ma być stronicowana, czy też nie. Kontroler jedynie mówi: ten i ten widok ma wyświetlić ten i ten model, nie mówi jak ma go wyświetlić, czy to ma być paginowalna lista, czy też nie. W tej implementacji MVC widok ma więcej zadań i w przeciwieństwie do znanych frameworków dla php potrzebnych będzie wiele klas widoku do różnych zadań.

Bezpośrednie powiązanie między widokiem, a modelem jest widoczne zwłaszcza w aplikacjach desktopowych, przykładowo Java i implementacja swingowej tabeli. Klasa JTable - widok, jest też jakaś klasa odpowiedzialna za model tabeli (nie pamiętam nazwy, pewnie JTableModel (IMG:style_emoticons/default/tongue.gif) ). Model przekazuje się bezpośrednio do konstruktora JTable, to widok bezpośrednio pobiera sobie dane z modelu, model może poinformować widok o tym, że zaszła w nim jakaś zmiana, a widok odświeży się (wzorzec obserwatora - pisał o tym @Zyx) - w aplikacjach www taki feature nie jest potrzebny gdyż http jest protokołem synchronicznym. Aplikacje dektopowe, a aplikacje internetowe to całkowicie dwie różne rzeczy, w aplikacjach www (mówię tutaj o frameworkach php) utarło się że to kontroler jest bliżej modelu niż widok, który służy tylko do prezentacji danych. Ma to swoje plusy oraz minusy.