Witam.
Zacznę od razu od jednego pytania bo już od dawna chciałem je zadać a nie chcę specjalnie tworzyć nowego tematu.. Czy z MVC można korzystać bez pisania w OOP?
A teraz pytanie dotyczące tematu:

Jak już wiem za co (mniej więcej) odpowiada model,view,control to teraz chciałem sprawdzić czy rozumiem rzeczywiście przebieg całej procedury.
Przede wszystkim wzorowałem się na zdjęciu który przedstawia MVC w UML

I teraz mamy np: controller posts. Przykładowo użytkownik kliknął na link: post o numerze 1024. Czyli adres miał taki: http://mojastrona.pl/posts/1024. W głównym pliku czyli index.php pobieramy z tablicy $_GET i 1 element świadczy o tym jaki kontroler mamy uruchomić. Czyli w naszym przypadku mamy do uruchomienia posts o nazwie kontrolera: postsController.
1)Teraz gdy już uruchomiliśmy nasz controler, on pobiera następnie 2-ugi element w tablicy czyli który post.
2)postsController przekazuje modelowi (postsModel) ten numer posta. On pobiera wszystko na temat tego posta i przekazuje tablice z powrotem do postsController.
3)postsController odbiera tablicę i następnie przekazuje go do widoku o nazwie postsView.
4)Nasz widok pobiera meta dane od postsModel który natomiast pobiera z bazy danych.
5)Wyświetla całe ciało i treść naszego posta 1024.

Czy dobrze to rozumuję, czy tak ma to wyglądać. Oczywiście każdy nasz postsController, articleController itp. dziedziczy główny Controller. I tak samo z innymi warstwami.

Dziękuję za wszelkie odpowiedzi i pozdrawiam.

BTW. W internecie jest dużo na ten temat ale wszędzie to samo czyli model to model tamto, kontroler to kontroler tamto...
A jak czytałem tutaj tematy o MVC to wynika z tego że jest pewien (niby) wzór ale każdy może to po swojemu interpretować. Zauważyłem kłótnie na temat tego czy widok ma mieć dostęp do kontrolera czy nie i tak samo czy widok ma mieć dostęp do modelu.

Pozdrawiam.

1. Możesz sobie darować możliwość powiadamiania warstwy widoku przez model (przez obserwatora) o zmianie swojego stanu, bo... Bo to jest aplikacja WWW, która w momencie wykonania się kończy swoje działanie. Mechanizm ten ma sens w aplikacjach desktopowych.
2. Błędnie zakładasz możliwość istnienia wyłącznie jednego widoku i modelu.
3. Czy model może zwracać dane do kontrolera? Oczywiście, że może, ale nie w celu przekazania ich do widoku - widok sam ma bezpośredni dostęp do modelu i to widok pobiera samodzielnie z niego dane, a nie otrzymuje je od kontrolera.

Niestety trzeba znaleźć jakiś złoty środek jeśli chodzi o sposób komunikowania się obiektów różnych klas. Wszystko zależy tak naprawdę od Twojej koncepcji i wygody. Ja lubię trzymać się pewnych konkretnych ustaleń: kontroler zarządza obiektami i ich komunikacją, więc widok dla mnie nie powinien nic wiedzieć o modelu, bo mogę chcieć przekazać do niego dane np. z pliku lub innych źródeł niż DB. Jeśli wszystkie obiekty będą nawzajem o sobie wiedziały - zrobi się spaghetti zależności, unikam takich rozwiązań.

@LSM: MVC zakłada, że widok komunikuje się z modelem więc ciężko, żeby o nim niczego nie wiedział. Ale komunikuje się z nim na podstawie interfejsu, nie klasy.

@Crozin: Jeden wzorzec można implementować na wiele różnych sposobów. To czy założysz, że widok komunikuje się z modelem zależy od Ciebie. Ja mogę uznać, że nie może się komunikować w ogóle z modelem, bo po co skoro już jest jedna klasa, która to robi czyli kontroler i wystarczy ją właśnie wykorzystać. Jeśli przyjdzie mi szukać węzła komunikacji to wiem, że mam na to przeznaczony właśnie kontroler, a nie widok. Wiem ponieważ koordynator czy kontroler w moich programach spełnia właśnie rolę pośrednika i zarządcy. Widok to widok - pod który możesz w skrajnym wypadku podpiąć dane z programu napisanego w .NET lub Java - wtedy opracowałbyś widok pobierający dane w postaci XML's np. SOAP aby kompletnie uniezależnić go od platformy silnika ... Tak widzę MVC - separacja zależności i odpowiedzialności, ale wersji MVC jest wiele ... :-)

LSM... I tutaj dochodzimy do sedna, czym jest MVC. Nie bede rozwlekał się, bo na tym forum już na ten temat napisano dziesiątki postów. MVC komunikuje model i widok tak jak jest na rysunku i o czym mówi Crozin. Ty opisujesz MVP, w którym Kontroler staje się Prezententerem danych z Modelu wewnątrz, zazwyczaj pasywnego, Widoku.

A dokładniej opisujesz MVP lub MVC z pasywnym widokiem, bo tak się ten wynalazek zwie, ale to nie jest MVC, tylko inny, choć podobny w budowie wzorzec. Wzorce po to mają swoje nazwy, by ich używać i by było wiadomo, o co chodzi.

Odpowiedź na pierwsze pytanie w temacie: można MVC zaemulować bez obiektówki, emulując samą obiektówkę w ten czy inny sposób.

Drugie pytanie: trochę inaczej.

1. Kontroler tworzy model.
2. Kontroler przekazuje ID posta do modelu.
3. Kontroler tworzy widok.
4. Kontroler każe widokowi korzystać z modelu.
5. Widok pobiera dane z modelu i je wyświetla.

@LSM: Odpowiedź podali już @thek i @Zyx ja chciałbym dodać tylko jedno - mylisz implementację i tworzenie założeń. MVC jak każdy inny wzorzec to jedynie zlepek założeń, teorii mówiącej o tym co powinno się dziać. Implementacja to realizacja tych założeń. Oznacza to mniej-więcej tyle, że nie masz prawa zmieniać założeń (szczególnie tych fundamentalnych) i nadal upierać się przy tym, że urzeczywistniłeś dany zbiór założeń, bo tego po prostu nie zrobiłeś. Masz prawo zadecydować o tym w jaki sposób model będzie informować widok o zmianie swego stanu (możesz to zrobić np. poprzez wykorzystanie obserwatora), masz prawo zadecydować o tym w jaki sposób kontroler będzie informować widok o tym z jakiego modelu ma on korzystać (możesz to zrobić np. poprzez wstrzykiwanie zależności) masz nawet prawo zadecydować o tym jak będą wyglądały wszystkie interfejsy komunikacji poszczególnych warstw, ale nie masz prawa zmienić założeń i wywalić jedną warstwę, a drugiej zmienić zasadnicze przeznaczenie.
Nie, jest jedna dosyć dobrze opisana. No może wspomniany przez @Zyxa MVC z pasywnym widokiem można by nazwać wariacją MVC. Innych wersji MVC nie znam. Jest cała masa wzorców wywodzących się z niego (MVVM, (H)MVP, HMVC, PAC - nie jestem pewien czy historycznie wywodzi się on z MVC, jeszcze kilka 3/4-literowców by się znalazło) ale to nie są "wersje MVC" tylko inne wzorce, ponieważ mają one inne założenia.

Dzięki :-)

@Crozin odnośnie implementacji jednego wzorca:
"Jest wiele sposobów implementowania jednego wzorca. [...] autorzy 'Design Patterns' bardzo starają się przedstawić różne sposoby implementowania każdego wzorca w części 'Uwagi o implementacji'. Gdy przeczytamy uwagi dotyczące wzorca Factory Method, dowiemy się, że istnieje bardzo wiele sposobów jego implementowania. [...]" - Joshua Kerievsky "Refaktoryzacja do wzorców projektowych"
oraz:
"[...] wygląda na to, że nie będzie za mało powtarzania, że diagram dołączany do opisu wzorca jest tylko przykładem, a nie specyfikacją. Ilustruje on najbardziej typową implementację. Jako taki będzie miał zazwyczaj wiele wspólnego z implementacją Czytelnika" - John Vlissides.

Jak rozumiem to ma być argument przeciwko moim poglądom? Nie miałem przyjemności przeczytania tego czy spojrzenia na zawarty tam kod, a takie krótkie i wyrwane z kontekstu cytaty nie są w tym przypadku warte zbyt wiele.

Ale jeżeli - podkreślam, jeżeli - jest tam coś takiego:To autor jest idiotą - podkreślam jeszcze raz, jeżeli jest tam coś takiego.

Odnoszę wrażenie, że Ty nadal nie rozumiesz, że wywalając z MVC założenia:
1. kontroler ogranicza się do operacji nie związanych z przetwarzaniem i wyświetlaniem danych oraz łączy ze sobą odpowiedni widok i model,
2. widok odpowiedzialny jest za tzw. logikę widoku oraz prezentację danych,
3. model i widok komunikują się ze sobą (bez)pośrednio,
Przestajesz tworzyć MVC, zaczynasz coś innego, ale z jakiś względów nadal upierasz się, że to jest właśnie MVC, tylko zadecydowałeś, że usuniesz z niego to, to i to, dodasz to, to i tamto oraz zmienisz to, to i jeszcze coś tam.

Wzorzec projektowy definiuje pewne założenia i by mówić o implementacji ów wzorca trzeba te założenia zrealizować. Już sama nazwa wzorzec wskazuje na to, że w różnych implementacjach pewne rzeczy będą takie same - dotyczy to wszystkiego, nie tylko programowania.

Nie zmieniałem założeń MVC. Źle zrozumiałeś co napisałem. Tłumaczyłem tylko że kontroler jest odpowiedzialny za aktualizację widoku. Nie jest to sprzeczne z założeniami MVC.
A co do idiotów to możesz pozdrowić jednego z bandy czworga bo o nim to właśnie pisałeś. :-)
Robię np. tak (pseudokod):

[PHP] pobierz, plaintext 
Contoller
{
function seeMe()
{
$model->setData();
$view->name = $model->name;
}
 
}
[PHP] pobierz, plaintext 

W ten sposób widok nie wie nic o modelu bo i po co ? Ale architektura złożenia MVC jest nadal zachowana - trzy warstwy odseparowane.

A to to niby co jest?Bo założenia MVC się z tym w ogóle nie pokrywają - wygląda na to, że po prostu nie znasz w ogóle założeń tego wzorca.

To teraz przeczytaj jeszcze raz co napisałem i zastanów się czy ja aby na pewno nazwałem autora idiotą.

Diagram wzorca nie jest tym czego trzeba się kurczowo trzymać - każdy zaimplementuje go na własne potrzeby. MVC jest zożeniem wzorców jak wiemy. Ale czy dodasz do niego obserwatora czy nie dalej będzie to MVC. Masz zawężone horyzonty.
A co do cytatów umieściłem je bo nikt nie zgadza się z tym co napisałem więc poszedłem po ratunek do literatury z resztą jednych z najbardziej znanych ludków w tym temacie.

Oczywiście, że nie. Ale w momencie gdy Twoje zmiany wyglądają już tak:To ciężko mówić o tym, że używasz MVC. Wziąłeś MVC, zmodyfikowałeś go i utworzyłeś coś nowego.
Dokładnie, dlatego właśnie mamy wiele implementacji różnych rzeczy (nie jest to związane wyłącznie z prog.). Ale by nasz twór nazywać jakąś ogólną nazwą wypadałoby by jego schemat użycia była taki sam albo różnił się tylko prawdziwymi detalami od wzorca. A im wzorzec dokładniej określa schemat użycia tym te detale które można zmienić stają się coraz drobniejsze.

Przykładowo: "Zbuduj silnik" i ja buduję spalinowy, a Ty elektryczny. Wszystko jest ok. "Zbuduj silnik zasilany prądem stałym" i ja buduję ładnie silnik elektryczny zasilany prądem stałym, a Ty prądem zmiennym i jeszcze upierasz się, że jest zgodnie z założeniami.

Nie jest. Nie określa on w jaki konkretny sposób warstwy mają się ze sobą komunikować, nie to jest ideą wzorca.

Tak, tylko że te cytaty w żaden sposób nie przeciwstawiają się temu co zostało w tym temacie powiedziane.

~LSM wierz mi lub nie, ale był już nie jeden, nie dwa i nie trzy tematy na tym forum i zawsze dyskusja kończyła się podobnie, każdy zostawał przy swoich racjach. Po prostu pewnych kręgów na tym forum nie przekonasz swoimi argumentami, choćbyś miał rację i choćbyś cytował im samych klasyków, znawców i twórców tematu, których intencje słusznie lub mniej słusznie odebrałeś. Tak to niestety wygląda, najczęściej obie strony mają trochę racji, ale każda z nich ciągnie w kierunku swoich argumentów.

Hmmm, masz dużo racji w tym co piszesz. Natomiast Twoim zdaniem jeśli widok nie będzie miał bezpośrednio powiązania z modelem to nie będzie już MVC. Moim zdaniem MVC polega głównie na separacji logiki pomiędzy trzy warstwy tak aby można było łatwo wymieniać widoki bez wpływu na model. Taka drobna zmiana, którą stosuje upraszcza pracę i pozostanę przy stanowisku, że nie burzy całkowicie idei MVC.

Tak, MVC może być traktowany jako osobny wzorzec ale również jako złożenie różnych - moje podejście nie jest błędne a Ty znowu stanowczo "Nie" :-) :
Z wikipedii:


Ty traktujesz go jako wzorzec sam w sobie i to też jest okej - nic do tego nie mam, dziwi mnie jednak Twój upór żeby coś mi za wszelką cenę wytłumaczyć i wyjeżdżasz mi jeszcze na temat znajomości podstaw :-). Ja Ci polecam podstawowe dzieło w tej materii bo mądrze i logicznie chłopaki to wszystko opisują.

Idąc dalej:

Kontroler zatem odświeża widok - ale to jak przekażę mu dane zależy ode mnie. To drobnostka, która nie niszczy całości. Trochę przesadzasz.
Nie wiem czy jest sens dalej kontynuować rozmowę - chciałbym pozostać przy tym, że po prostu mamy nieco inne spojrzenie na problem i wykorzystywanie wzorców i czym one są.



Zgadzam się w 100% i rozumiem stan rzeczy, ale po to jest forum żeby przedstawiać swoje punkty widzenia.

@Crozin w jaki sposób przekazujesz dane do widoku skoro jak piszesz:

Czyli w zasadzie potwierdzasz co napisałem odn. diagramu autora postu - że obserwator tutaj nie jest potrzebny.
To mnie ciekawi...

W diagramie autora postu nie podoba mi się obecność tej samej odpowiedzialności (ustawModel()) w dwóch klasach o różnych rolach (Widok i Kontroler) i do tego odnosiłem swoje wypowiedzi. :-)

Jeśli już cytujesz wiki to sięgnij nie do polskiego tłumaczenia, ale angielskiego:

To raz... Ogólne działania na grafie masz tu:
I jak byk wynika tutaj, że Kontroler może zmienić Model lub Widok, bądź jego stan, ale dane pomiędzy Widokiem a Modelem przepływają w tym wzorcu POMIĘDZY nimi, a nie za pośrednictwem Kontrolera.

Teraz sięgamy po opis MVP na WIki i czytamy, że:

Widzisz różnicę, która staramy Ci sie nakreślić? Opisujesz już istniejący wzorzec (MVP), ale nazywasz go błędnie (MVC). Z tego samego źródla czytamy już w pierwszym zdaniu:

Czyli znów potwierdzenie tego co Ci piszemy, a więc że choc podobne, to nie jest to samo Dlatego jeśli cytujesz już źródła na Wikipedii, to przeczytaj je dokładnie i nie ograniczaj tylko do polskich.

MVC traktuje o tym jak te trzy warstwy się ze sobą komunikują. Trójpodział i komunikacja - to są dwa główne założenia tego wzorca. Modyfikując je w takim stopniu jak proponujesz tworzysz coś innego. Sama idea trójpodziału (albo i jeszcze większa) jest stara jak świat i nie jest to nic czym by się MVC wyróżniało.

Tutaj wyszło nam małe nieporozumienie. Inaczej zinterpretowałem Twoje "wzorzec złożony". Tutaj się zgadzam, ponieważ na dobrą sprawę ciężko jest tak rozbudowane narzędzie napisać nie wykorzystując przy tym innych, mniejszych.

Nie do końca. Pamiętaj o tym, że mówiąc o MVC trzeba mieć przede wszystkim w głowie obraz typowej aplikacji desktopwej. Generalnie widok sam się odświeża (kliknąłeś "pokaż stronę 2" i jedynce co się dzieje to poproszenie przez widok modelu o zwrócenie następnej porcji danych). Kontroler odświeża widok w momencie gdy trzeba np. ów widok zmienić (przykładowo z tabelarycznego na listę). Trzeba również mieć na uwadze, że w przypadku aplikacji webowych każde odświeżenie wiąże się z nowym żądaniem, które siłą rzeczy musi wywołać kontroler.

Chodzi też o to, że ja tutaj mógłbym dla każdego cytatu zamiast odpisywać podać po 2-5 linków do innych wątków tłumaczących konkretne arguemnty. W skrócie: było 534534534 razy.

Aplikacje www mają to do siebie, że po wyświetleniu HTMLa w zasadzie kończą swój żywot. Nie ma możliwości by model powiadomił widok o zmianie swego stanu (co się dzieje np. w przypadku aplikacji obiekowej gdy po kliknięciu "przetwórz dane" model przez 20 sekund je przetwarza informując co jakiś czas widok o postępie, aż w końcu informuje go o tym, że może poprosić o dane). W aplikacji webowej ten proces jest wykonywany tylko raz, na samym początku. Widok od razu prosi model o dane, wyświetla je i nie ma już szansy poporisić znowu bo kończy swoje działanie.


Dlaczego się tak czepiam? Bo niszczysz ideę wzorców projektowych. Ich zadaniem jest nazwanie jakiś typowych struktur, które występują w kodzie, któe rozwiązują typowe problemy. Na wzorzec składa się jego nazwa, zbiór założeń i przypadki w których jest sens jego ewentualnego użycia. Różne implementacje same w sobie nie są częścią wzorca. Mój problem? Jak ktoś mówi mi, że ma aplikację napisaną w oparciu o MVC to powinienem wiedzieć od razu jak ona działa. A nie wiem. Czemu? Bo Ty sobie z MVC wywalisz to, ktoś tam tamto, jeszcze ktoś dołoży coś nowego, ja będę się trzymać założeń MVC itd. Innymi słowy MVC przestało być wzorcem, bo nie wiem czego się spodziewać po "aplikacji opartej na modelu MVC". MVC przestało być wzorcem bo nie ma on w takim przypadku zdefiniowanych założeń, a jeżeli są to są sprzeczne między sobą.

Ale jazda :-)
Masz rację thek, dzięki za diagram. Jednak MVP to:

No właśnie - ja pisałem ogólnie o MVC, wy trzymacie się konkretnych podziałów. Dobra rozumiĘ.
Dla żartu - czy prezenter to też kontroler ?

[PHP] pobierz, plaintext 
PrezenterContoller
{
function seeMe()
{
$model->setData();
$view->name = $model->name;
}
 
}
[PHP] pobierz, plaintext 

Można i tak:

[PHP] pobierz, plaintext 
$model->setData();
$view->setModel( $model );
[PHP] pobierz, plaintext 

Ok teraz rozumiem o co wam chodzi - zwracam honory Crozin. ;-) Postrzegałem wszystko zbyt ogólnie i mało precyzyjnie.

I właśnie o to chodziło LSM Byś zauważył, że są pewne różnice między wzorcami MVC i MVP.

A co do Twojego żartu, to... nie jest żartem Prezenter w MVP przejmuje rolę Kontrolera z MVC i dodatkowo zostaje komunikatorem obu pozostałych warstw w miejsce usunietych połączeń. Gdy nadchodzi żądanie, prosi on Model o dane oraz wybiera Widok. Gdy zaś otrzymuje dane z Modelu, przekazuje je do Widoku. Tak więc Twój kod jest prawidłowym przykładem uproszczonej maksymalnie implementacji Prezentera.