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

[bumelang]

Wszystko wskazuje na to, że mamy odmienne pojęcia na "abstrakcję źródła danych". Z tego, co wiem, to w typowym znaczeniu oznacza ona po prostu klasę dostępową do źródła, niezależną od implementacji na konkretnej bazie danych czy pliku - taki API, jak np. AdoDB.

Innymi słowy, w 3-warstwowym modelu aplikacji najniżej jest warstwa dostępu do danych (do której API dostępu z warstwy drugiej można określić "abstrakcją na źródło danych", jeśli takie jest zastosowane).

Warstwa druga, która jest najczęściej modelem, stanowi tymczasem zbiór klas czy funkcji tzw. "logiki biznesowej", co przede wszystkim oznacza, że ta warstwa + warstwa danych tworzy gotową aplikację - realizuje wszystkie zadane operacje na bazie danych, uwierzytelnianie użytownika, tworzy jakieś logi, wywołuje jakąś usługę SOAP, wysyła maila, cokolwiek, ale jest to kompletny, działający system, tyle, że zamiast interface'u użytkownika udostępnia API programistyczne dla warstwy jeszcze wyższej.

Warstawa kontrolera i widoku to tymczasem warstwa prezentacji, czyli jeszcze wyżej. I teraz wygląda to tak, że użytkownik się loguje, łaczy się z kontrolerem, któremu przesyła żądanie, ten czyści dane wejściowe i jeśli wszystko jest ok wywołuje funkcję zaloguj($login, $haslo) warstwy logiki biznesowej (czyli model) i sprawdza, czy to się powiodło, ale nie wie nic o szczegółach implementacji w modelu i - przede wszystkim - nie ma dostępu do bazy danych, nie może wywołać żadnego zapytania SQL. Później kontroler przekazuje sterowanie do odpowiedniego, w zależności od powodzenia operacji, widoku - ale to jest jasne.

Oczywiście 3-warstwowy model aplikacji jest tu tylko po to, żeby objaśnić zagadnienie modelu jako takie w kontekście "abstrakcji źródła danych". W rzeczywistym systemie z zastosowanym MVC mogą być z równym powodzeniem tylko 2 warstwy - sama prezentacja i model.

Jak widzisz, być może że tylko 1 pojęcie sprawiło, że myślisz, że tego nie rozumiesz, a rozumiesz - jeśli tak to sorry za zamotkę