[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]

@ogólnie:

Nie ma sensu zastanawiać się, czy model jest jeden, dwa czy dwadzieścia. Model to tylko warstwa. To tak jakby mieć dwie warstwy bazy danych. Można mieć dwie bazy danych, ale obie należą do warstwy bazy danych. Masłomaślanizm powyższego dowodzi, że mówienie o modelach jest bez sensu.

Ja jestem przeciwny jakiemuś akcentowaniu w nazwach itd. że mamy do czynienia z modelem. Po prostu klasy Article, User, itd. Cała zabawa polega przecież na tym, żeby model był odseparowany od HTTP i innych okropności. Żeby był to ładny, elegancki projekt obiektowy (OOD), bez zawiłości protokołów, sesji, itd. Więc nie żadne $model->getData(), nie żadne metody modelu, tylko po prostu $articleContainer->getArticleById(12345) itd.

A nazywanie klasy ArticleModel jest niekorzystne z tego powodu, że skoro model jest odseparowany od całej reszty, to też nie wie nic o kontrolerze i o MVC. Jak tworzę klasę do artykułów, to nazywam ją Article. Jak tworzę klasę do artykułów w aplikacji MVC, to powinienem postępować tak samo jak poprzednio. W końcu o to chodzi w MVC.

@dag:

To już zagadnienie nie MVC, tylko ogólnie OOD, ale podane przez ciebie metody do Article(Model) są złe. Tzn nie złe z punktu widzenia modelu, tylko złe z punktu widzenia hierarchii klas. Jeżeli są sobie artykuły, to logiczne jest, że potrzebuję klasy Article. Ale potrzebuję też kontenera artykułów. Inaczej się nie da tego sensownie zrobić. Jeżeli mam zbiór artykułów (a przecież mam), to ten zbiór musi być "czymś", czyli musi mieć obiekt. A jak obiekt to i klasa. Kontener. Na tym etapie też robi się tzw. projekt trwałości, czyli po ludzku zaznacza, co siedzi w bazie danych (artykuły). I kontener je wyciąga.