[MVC] Pytań kilka... Opcje

[Zepco]

Ponieważ nie mam dostępu do forum DEV, a wiem, że tam po części problem MVC był poruszany, postanowiłem zadać kilka pytań.

Coraz więcej mówi/pisze się na temat MVC (Model-View-Controller) ale pomimo usilnych starań nie mogę zrozumieć pewnych mechanizmów, tymbardziej, że większość przykładów podawanych jest w Java'ie.

Może zacznę od tego co już wiem, jeśli się mylę, proszę poprawcie mnie. (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Cała aplikacja składa się z trzech części:

:arrow: Kontrolera, który odbiera operacje z zewnątrz (input) i odpowiednio je przetwarza, wywołując konkretny model (modułu) i metodę tegoż modelu. Może również odwoływać się bezpośrednio do widoku.

:arrow: Modelu, który jest niejako modułem odpowiedzialnym za jakiś ułamek pracy aplikacji (menu, news, sonda itp, itd.). Także jak widać w przeciwieństwie do kontrollera istnieje wiele modeli. Jak wcześniej wspomniałem model odbiera od kontrolera odpowiednie rządania, przetwarza je i wynik może przesłać do widoku.

:arrow: Widok natomiast wszystkie dane wysłane z modelu lub kontrolera wysyła na zewnątrz (wyświetla wynik na WWW, tworzy dokument XML, PDF itp.). Tak więc może być kilka podwidoków, które wywołane przez widok głowny tworzą efekt końcowy widoczny dla użytkownika.

A teraz czas na pytania:
* w jaki sposób elementy te komunikują się?
* wiem, że najbardziej naturalnie będzie zastosować programowanie obiektowe, ale czy da się to zrobić strukutralnie?
* co jest w przypadku gdy jeden model jest zależny (potrzebuje danych) od drugiego modelu?
* czym są akcje (actions) i łańcuchy (chains)?

Jeśli coś pominąłem, proszę dopiszcie, Myślę, że dyskusja na ten temat wpłynie w jakimś stopniu na rozpowrzechnienie tego rozwiązania, a chyba na tym nam zależy, aby łatwiej tworzyć aplikacje webowe i w przyszłości korzystać z już napisanego kodu...

[hawk]

Oczywiście że model nie powinien korzystać z żadnych globalnych tablic, bo nie ma tam nic co mogłoby być mu potrzebne. Natomiast ciekawe jak napiszesz kontroler który w ogóle nie rusza tablicy $_POST, chociażby bo to aby gdzieś przepisać jej zawartość (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) .

Po co ci wiele kontrolerów? Chyba że mówimy o Page Controller, ale MVC raczej operuje na jednym, centralnym kontrolerze.

Jeżeli chodzi o model i akcje to ni <męski narząd moczowo-płciowy> nie mogę nic z tego wyrozumieć. "model to klasa ktora jest interfejsem wywołującym konkretną akcje"? Klasa nie jest interfejsem, to raz. Dwa, że obiekt modelu absolutnie nie powinien wywoływać metody obiektu akcji. Jak by to miało wyglądać? No chyba że mówimy o listenerze w Smalltalku/Swingu, ale to inny MVC niż w php i raczej nie o to nam chodzi (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) .

BTW, dlaczego z MVC jest tyle zamieszania? Mi się wydaje że to bardzo naturalny sposób tworzenia aplikacji, i jakby nie był wymyślony, to i tak ludzie sami z siebie by do tego doszli (IMG:http://forum.php.pl/style_emoticons/default/blink.gif) .

BTW2, Marcin wyrasta nam na eksperta od MVC, który nie tylko wie co i jak ale i potrafi to łopatologicznie wyjaśnić (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

----------------------------------------
Grr, dlaczego nie mogę dać 2 odpowiedzi pod rząd? (IMG:http://forum.php.pl/style_emoticons/default/aaevil.gif)
@Ozzy:
IMHO to nie tak. MVC w Swingu sporo różni się od tego w php, bo inny jest model interakcji. Więcej, MVC w Swingu różni się od tego w JSP i Struts, z takich samych powodów.
Natomiast używanie MVC na siłę oczywiście jest stratą czasu. Zwłaszcza w php gdzie wczytywanie kolejnych klas jest tak popieprzone jak jest. php na ogół stosowane jest do prostych serwisów. Serwisy banków już raczej w JSP. Dlaczego? Bo php jest zbyt prymitywny do tego celu. Jeżeli php dalej ma się rozwijać do Personal Home Page, to nie ma problemu, można sobie zlać MVC, wzorce i w ogóle wszystko to co wprowadzili w PHP5 bo bez tego też się da. Ale całe te zmiany idą (chyba) w kierunku uczynienia z php dobrego języka na poziomie "enterprise". I wtedy Smarty przestaje wystarczać, i trzeba pomyśleć np. o modyfikowalności itd.