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

[rzseattle]

No wiec tak sorry ale odpowiem nie po kolei :

ad 4

Akcje sa to logicznie podzieone operacje tzn ze w akcji starasz sie zawrzec najbardziej niepodzielna operacje jaka sie da. Czyli na przyklad akcje : zaloguj, usun artykul, dodaj artykul, pokaz menu itd. Akcje dzielimy naa logiczne i widoki. Akcje logiczne sa odpowiedzialne za realizacje zadan takich jak dodaj, usun, powiarz, sprawdz itd. podczas gdy akcje widoki maja za zadanie zwrocic dane do przegladarki.
Łancuch akcji polega na tym ze jezeli wciskasz przycisk usun artykul to najpierw wlacza sie akcja potwierdzajaca wybor potem ta akcja uruchamia akcje usuwajaca artykul ktora z kolei wywluje widok pokazujacy liste artykulow, taki lancuszek.

ad 1

Kontroler dostajac odpowiednie dane uruchamia odpowiednia akcje ktora uruchamia odpowiedni model. Mozna ten schemat komplikowac ale generalnie tak to wyglada.

ad 2

Jesli udalo by ci sie to oprogramowac strukturalnie to ja chcialbym taki silnik zobaczyc

ad3

Wlasniesie spotkalem z takim problemem. No coz poprostu w akcji uruchamiam dwa modele.

ps Dodamtylko ze zadaniem modelu jest tylko i wylacznie stworzenie abstrakcji na dane tak aby jezeli sie cos zmieni np. w bazie to grzebiesz tylko w modelu a nie we wszystkich akcjach.

[radziel]

[...] Modelu, który jest niejako modułem odpowiedzialnym za jakiś ułamek pracy aplikacji[...]

Mylisz dwa pojęcia,
model ma za zadanie komunikację z bazą i zwracanie danych.

moduł to zbiór akcji które sąodpowiedzialne za "przetwarzanie" danych z modelu.

Mam nadzięję że dobrze wytłumaczyłem

[rzseattle]

Mylisz dwa pojęcia, 
model ma za zadanie komunikację z bazą i zwracanie danych.

moduł to zbiór akcji które sąodpowiedzialne za "przetwarzanie" danych z modelu.

Mam nadzięję że dobrze wytłumaczyłem

No nie do konca . To nie musi byc koniecznie baza danych, moga byc pliki, xml czy jeszcze jakies inne zrodlo danych.

[radziel]

No nie do konca . To nie musi byc koniecznie baza danych, moga byc pliki, xml czy jeszcze jakies inne zrodlo danych.

No tak, ale wkażdym razie model zwraca dane do obróbki

[Zepco]

No wiec tak sorry ale odpowiem nie po kolei :
ad3

Wlasniesie spotkalem z takim problemem. No coz poprostu w akcji uruchamiam dwa modele.

Nie wiem czy dobrze rozumiem, ale w pliku konfiguracyjnym mógłby być wpis o zależności (dependencies) od innego modelu.

A jak sprawa ma sie z widokiem i podwidokami?
Czy widok jest tą klasą główną, która wysyła dane do odpowiedniego podwidoku, a ten wysyła go na wyjście, czy też wyborem widoku zajmuje się kontroler?

[rzseattle]

Nie wiem czy dobrze rozumiem, ale w pliku konfiguracyjnym mógłby być wpis o zależności (dependencies) od innego modelu.

A jak sprawa ma sie z widokiem i podwidokami?
Czy widok jest tą klasą główną, która wysyła dane do odpowiedniego podwidoku, a ten wysyła go na wyjście, czy też wyborem widoku zajmuje się kontroler?

Jak juz wspomnialem model jest klasa tworzaca abstrakcje na zrodla danych, wiec jesli potrzebuje w danej akcji dwoch modelow to poprostu includuje oba i kozystam z dwoch przy czym jeden o drugim nie musi nic "wiedziec".

Nie rozumie co rozumiesz przez polwidok?? Akcje logiczna?

Lancuszek akcji jest tworzony w ten sposob:

1) Router "dekoduje" url i wysyla do kontrolera jak akcje ma uruchomic
2) Kontroler sprawdza czy akcja potrzebuje zalogowania , czy jest plik akcji itd...
3) Kontroler uruchamia akcje.
4) Akcja wykonuje sie i po zakonczeniu wywoluje inna akcje
5) Na koncu jest zawsze akcja - widok ktora wysyla dane do przegladarki i nie wywoluje juz innej akcji
6) Wykonywany jest destruktor kontrolera

THE END

Przedstawilem to w sporym uproszczeniu, ten schemat tez mozna komplikowac, ale mniej wiecej tak to dziala.

[Zepco]

Specyfikacja URLa oczywiście nie ma znaczenia i zależy jedynie od wyobraźni twórcy?
Czy dane wysłane przez POST i GET oraz te, które są zawarte w SESSIONS wyciągane są bezpośrednio przez modele, czy też tym też zajmuje się kontroler?

[radziel]

Specyfikacja URLa oczywiście nie ma znaczenia i zależy jedynie od wyobraźni twórcy?
Czy dane wysłane przez POST i GET oraz te, które są zawarte w SESSIONS wyciągane są bezpośrednio przez modele, czy też tym też zajmuje się kontroler?

Zajmuje się tym kontroler - najlepiej napisz klasę / funcję (zależy jak programujesz ), która będzie zajmować się danymi z input'a.

[rzseattle]

Specyfikacja URLa oczywiście nie ma znaczenia i zależy jedynie od wyobraźni twórcy?

I od konfiguracji serwera

Czy dane wysłane przez POST i GET oraz te, które są zawarte w SESSIONS wyciągane są bezpośrednio przez modele, czy też tym też zajmuje się kontroler?

Nie trzeba MVC zeby wiedziec ze w pozadnym silniku nie uzywa sie tych tablic ( bezpieczenstwo). Tak na wstepie konstruktor kontrolera powinien wywolywac obiekt input ktory zajmie sie skladowaniem danych zewnetrznych. Sesje tez najlepiej zamaskowac pod jakas metoda kontrolera. Pamietaj tez ze zmienna z jednej akcji nie bedzie widoczna w drugiej wiec tez musisz pomyslec nad sposobem przekazywania tych zmiennych. Najlepiej wtedy dodac opcjonalny argument dla metody zapisujacej zmienna ktory powie "umiesc mnie w sesji" .

ps Nie przesadzaj z tym Pomogl Mi

[kubatron]

A mógłbym zapytać gdzie to można ściagnąć jak zainstalować,jakis kurs/manual i co to jest

[scanner]

Jeden z dostępnych: http://phiend.sourceforge.net

[Nalfein][WR]

Nie wiem czy dobrze rozumiem, ale w pliku konfiguracyjnym mógłby być wpis o zależności (dependencies) od innego modelu.

Mógłby być, ale po co. Możesz po prostu includować (bezpośrednio przez include() lub przez inny obiekt - menedżera klas aplikacji) plik z klasą odpowiedniego modelu z poziomu innego modelu.

A jak sprawa ma sie z widokiem i podwidokami?
Czy widok jest tą klasą główną, która wysyła dane do odpowiedniego podwidoku, a ten wysyła go na wyjście, czy też wyborem widoku zajmuje się kontroler?

Wyborem widoku zajmuje się kontroler, a raczej (przeważnie) ostatnia akcja w łańcuszku, tutaj nazywamy ją akcją widoku, gdzieniegdzie możesz ją znaleźć pod nazwą kontrolera widoku (ViewController). W niej ładujesz i wypełniasz szablon. Akcja widoku wypełnia sam widok, czyli przeważnie szablon Smarty, arkusz XSLT. Sam widok przeważnie nie jest klasą, chyba, że zastosujesz technikę kompilacji szablonów do klas. Na razie takiego engine-u pod php nie ma, ale już się robi (u mnie ). Do widoku przekazujesz dane, porcję danych, możesz ją przechowywać w osobnej warstwie obiektów typu DataSpace/DataProvider, wtedy akcja widoku po prostu wybiera obiekty "dostawców danych" i obiekt(y) "widoku". Podwidoków w php nie ma wyodrębnionych jako tako, gdyż jak już wspomniałem widok jest płaski, inne widoki po prostu {include}-ujesz przez Smarty jak zwykłe fragmenty szablonów.

[bumelang]

Jak juz wspomnialem model jest klasa tworzaca abstrakcje na zrodla danych [ciach!]

Może jestem nadgorliwy, ale chodzi bardziej o to, że w kontrolerze nie są podejmowane żadne działania z zakresu logiki aplikacji. Kontroler steruje widokami, czyli po prostu interface'm użytkownika, zaś całość logiki zawiera się w modelu. Różnica jest taka, że model nie reprezentuje źródła danych. Fakt, że typowy model to np. wywołanie
[php:1:e6cd80946a]$managerProduktow->dodajProdukt($p)[/php:1:e6cd80946a]
ale od abstarkcji na źródło danych różni się to tym, że model może tu robić niezłą zamotkę z danymi, która z punktu widzenia kontolera jest nieistotna, i tu jest prawdziwy zysk - ktoś zmienia implementację logiki, ale logika prezentacji się nie zmienia.

Z resztą nie da się ukryć, że MVC ma największy sens przy aplikacjach heterogenicznych, gdzie model jest napisany w innym języku programowania, albo przynajmniej jest uruchamiany na innym serwerze.

[rzseattle]

zaś całość logiki zawiera się w modelu.

Musze przyznac ze sie pogubilem. Tworzac pod MVC nie spotkalem sie z sytuacja kiedy model w oparciu o dostarczone mu dane mial decydowac co ma zrobic ( a tak chyba definiujemy logike aplikacji :?: ), wrecz przeciwnie wszystko jest umieszczone w pojedynczych akcjach i to one decyduja co zrobic, przekazujac to modelowi ktory wie jak i gdzie. Jakdla mnie to jest czysta abstrakcja na zrodlo danych

... ale od abstarkcji na źródło danych różni się to tym, że model może tu robić niezłą zamotkę z danymi, która z punktu widzenia kontolera jest nieistotna, i tu jest prawdziwy zysk - ktoś zmienia implementację logiki, ale logika prezentacji się nie zmienia.

Jesli mozna wiedziec to co rozumiesz przez "zamotke z danymi". Bo dla mnie zbior operacji ukryty pod jedna metoda to juz jest abstrakcja i biorac pod uwage ze model zajmuje sie danymi zewnetrznymi ( przeciez nie robimy w akcji $mathModel->dodaj($this->input['a'], $this->input['b'], $this->input['c']) ) to dla mnie jest to abstrakcja na zewnetrzne zrodla danych. A to czy operacje na danych sa proste czy skomplikowane to mnie nie interesuje.

No ale moze zle rozumie stwierdzenie "Logika aplikacji"

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

[rzseattle]

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.

No maly OT sie zrobil. Ale czy udostepnianie API programistycznego ktore maskuje wszelkie zrodla danych i nie wymaga wiedzy skad i dokad podazaja zmienne nie jest abstrakcja na zrodlo. Dla mnie wlasnie tu jest granica - Dopiero tam gdzie przestajemy sie interesowac czy dane pochodza z ADoDB czy jakiegos obiektu obslugujacego XML konczy sie abstrakcja. Ale rozumiem twoje podejscie , jednak zauwaz ze np ADoDB tez udostepnia API programistyczne ktore ulatwia obsluge bazy danych.

No ale jak juz powiedzialem OT .

[bumelang]

Być może to jest OT, ale nie wiem, czy można nazwać abstrakcją na źródło danych coś, co nie koniecznie operuje na danych w bazodanowym sensie i nie koniecznie ma dostęp do źródła danych. Przecież model może np. pobrać informacje o dostępności produktu przez SOAP, sprawdzić stan rachunku bankowego, zamówić produkt i przelać kasę. I to wszystko w jednym wywołaniu modelu.

A warto też dodać, że model może być np. aplikacją w C, która ma za zadanie obliczyć symulowane odsetki, a kontroler tylko robi exec('/usr/bin/odsetki -sklada_miesieczna 3000');

[Zepco]

Jak dla mnie takie OT mogą być, o ile mieszczą się w pewnych ramach tematu tak jak powyższa polemika. :-)

Tak na marginesie chciałem zapytać skąd czerpaliście informacje na temat MVC?

[Sh4dow]

Moze troche sie wtrącam do waszej zrozmowy, ale moze powiecie mi pare rzeczy. Jako ze nie obeznany jestem tak jak Wy, nie zawsze kojaze co za skroty uzywacie, albo jakies pojecia anglojezyczne. No ale nie o oto i do konca chodzi. Jak napisal scanner ze jeden z takich MCV jest dostepny na necie oczywiscie tam zagladolem. Ale niestety moja wiedza tajemna nie byla wstanie przegrysc samego manuala, wiec o testach na phiendzie nie bylo mowy.
Ale po kolejnych postach zaczyna cos mi swiatac na temat calego tego MVC.

Bumelang napisał o 3 warstwowym poziomie aplikacji, szczerze mowiac dopiero jego post dal mi do myslenia jesli chodzi o cale zagdanienie MVC.

Jesli dobrze zrozumialem do pierwsza warstwa jest odpowiedzialna za pobranie danych, naprzyklad skrypt rozpoznaje zapytanie, np User chce zobaczyc na stronie komantarze do artykulu, wiec skrypt rozpoznaje ze chodzi o komentarze o jakies danej specyfikacji, wiec lpobiera dane dla tej specyfikacji (pliki, bazy danych, sockets itd). Procz tego apytania, sa standardowe zapytanie, powiedzy o konfiguracje strony (tytul, adres, kolor itd). Jako standardowe zapytanie przy wiekszosci odslon.
Ta warstwa teoretycznie konczy swoje zadanie i przesyła dane do drugiej warstwy, której zadaniem jest przetworzenie wszystkich otrzymanych danych. Tutaj nawołując do przykladu, skrypt powiedzmy ze w komentarzach przetwarza text (np BBcode) ustawia zapis daty i jakie pare tam innych opcji mniej waznych.
Przetworzone dane wędruja teraz do warstwy ktora zajmuje sie wyswietlanie, powiedzmy ze beda to Smarty, które generuja nam gotowy kod wysylany do przegladarki. i tutaj piszecie jeszcze o wykonaniu destruktora.

A teraz pare Pytanek:
- czy dobrze zrozumialem to zagadnienie? oczywiscie jest ono mocno uproszczone.
- czy warstwa 2(czyli przetwarzanie danych) moze czesciej pobierac dane z 1 warstwy? Np. po otrzymaniu danych, podczas przetwarzania pobrac dodatkowe informacje, czy trzeba przewidziec to w 1 warstwie i wyslac odrazu.
- czym jest destruktor, jakie jest jego działaniei i co sie stanie jesli go nie bedzie?

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.

czy zalozenie 2 warstw mam rozumiec poprze poprzez polaczeni pierwszej i drugiej? Ma to jakas zalete?