Witam,

Zapoznaję się właśnie z czymś takim jak MVC, napisałem sobie trochę kodu który przypomina frameworka
Problem w ty że gdzie o tym nie poczytam to coś innego piszą - jakie powinny być relacje widoku modelu i kontrolera?

Moje pojęcie jest takie:

Kontroler wybiera odpowiedni model, wykonuje wszystkie operacje logiczne związane z daną akcją po czym pobiera odpowiednie dane z modelu i je przekazuje do widoku (żeby operować na ładnych przykładach niech będzie to lista newsów) który to widok z tych danych generuje kod html dla użytkownika.

Model odpowiada za operacje na danych, ich zmianę oraz pobieranie. Jeśli kontroler musi np. usunąć newsa to wywołuje odpowiednią metodę modelu.

Widok operuje jedynie na danych przekazanych mu przez kontroler, nie ma dostępu do modelu.


Czy ta filozofia jest prawidłowa? Na wikipedii w schemacie widok ma połączenie z modelem, ale w tym momencie nie za bardzo rozumiem w jakim celu.

Rozne sa interpretacje, generalnie chodzi o to zeby te trzy warstwy byly jak najmniej ze soba sprzegniete. Mozna logike wyrzucac do modeli, mozna czesciowo (np. validacja formularza, wyslanie maila) trzymac ja w kontrolerze.
Kontroler moze pobierac z modelu i przekazywac do widoku, moze rowniez tylko wywolac odpowiedni widok ktory sam sobie dane z modelu zaciagnie, w tym wypadku musialaby byc dodatkowa warstwa pomiedzy na przyklad systemem szablonow, a kontrolerem.
Ja osobiscie w kontrolerze decyduje co ma zrobic model, przypisuje widokowi dane z modelu i kaze mu sie sparsowac.
Rozni developerzy roznie programuja, mnie osobiscie najbardziej przypasowal jak do ten pory MVC zaimplementowany w Zend Frameworku. Innych nie probowalem jedynie czytalem pare tutoriali.

Jestem zdania że widok powinien dostać dane i tylko je wyświetlić, zero interakcji z innymi elementami.
Model powinien pobierać dane ale właściwie nic nie robić z nimi.
Kontroler ja opiszę na postawie frontcontroler (czy jak się to zwie) czyli jest główny który uruchamia dla konkretnego adresu odpowiedni "podkontroler" i ten pod kontroler wie z którego modelu pobrać dane je przekazać do widoku jak również przyjąć dane od użytkownika zweryfikować je i przekazać do odpowiedniego modelu.

Dlaczego uważam, że widok powinien tylko użyć dane przekazane do niego? Bo już raz miałem kłopot z powodu tego że odwoływał się do modelu, czy też danych sesyjnych. Czyli moim zdaniem to kontroler powinien decydować jakie dane przekazać do widoku o ściśle określonej strukturze. (aby osoba odpowiedzialna za wygląd wiedziała do czego ma dostęp)

Ale każdy może uważać inaczej.

@Sedziwoj - Jak tylko opracują protokół przesyłania wódki przez net, to Ci pół litra wyślę, bo mam takie samo zdanie na temat widoków : P

Pozdrawiam.

Witam,

jestem nowym użytkownikiem i mało wiem o MVC ale jesli moge sie wypowiedziec to wg mnie powinno wyglądać to tak(na prostym przykładzie newsow który podałeś):

1. MODEL - tworzysz sobie klase newsow w ktorej wpisujesz rozne metody takie jak np updateNews(), addNews(), deleteNews(), checkNewsForm() itd ........ . Czyli w tej klasie posiadasz wysztko co jest niezbedne do obslugi newsow (wszystkie metody itd.)
2. CONTROLLER - Poprzez odpowiedni odwołanie z URL np za pomoca $_GET twoj system wybiera odpowiedni controller np usuwanie newsa, controller odwoluje sie do klasy News() a w niej do metod: checkExistsNews(), deleteNews() (czyli rola controllera jest wybranie odpowiedniej metody,co musisz recznie ustawic ), Controller na koniec swojego dzialanie przekazuje dane do np jakiegos systemu szablonow:$smarty->assign(); przekazujac modelowi rozne dane takie jak nazwe news ktory chcesz usunac itd., wybiera odpowiedni szbalon
3. View to wg mnie nic innego jak zwykly plik np. tpl lub nawet .php do ktorego contorller przekazuje dane ktore model ma wyswietlic.
Główna zasasda MVC jest to aby w modelu byl tylko kod php a w VIEW tylko html , w controlerze nie pamietam
jestem po pary glebszych wiec moge sie mylic ale zasada MVC jest odseparowanie od siebie tych 3 czesci Model View Controller

@radzik_w
Ogólnie to jest rozdzielenie na trzy niezależne warstwy.
Czyli model pobiera dane, ma swój interfejs getNews add itd. ale wszystko co odwołuje się do źródła danych, najczęściej baza ale właśnie nie zawsze musi być, jak również strukturę danych ukrywa pod interfejsem.
Kontroler wie skąd brać dane (z którego modelu/i) i czy coś musi spr. jak poprawność, czy wszystko wprowadzone weryfikacje osoby (choć to już zależy jak się to robi) i przekazuje dane do widoku/modelu (w zależności czy zapisuje czy wyświetla, lub oba naraz).
Widok wie tylko jak ma te dane wyświetlić, kontroler nawet nie wie czy widok będzie xml, html czy czymś innym. (właśnie zdałem sobie sprawę ze to co ostatnio robiłem do tworzenia pdfów to powinno istnieć jako widok , a ma różne widoki bo zostało specjalnie właśnie do elastycznego podmiany generacji... ale to juz inny temat) czy zapisania do pliku.
Czyli kontroler zbiera dane obrabia dane i je przekazuje do widoku i go nie obchodzi co widok z nimi robi, tak jak nie obchodzi go skąd model bierze.
(Widok to można powiedzieć że piszemy artykuł tytuł treść wrzucamy przez szparę w drzwiach i nie wiemy czy pójdzie to do gazety czy telewizji czy radia a może do kosz:D)

Dzięki takiemu podziałowi można łatwo zmienić skąd są pobierane dane, jak również jak są prezentowane.
Bo zmienię że zamiast do szablony smarty wysyłam do generatora pdf ale tylko to czyli w sumie jedną zmienną, a zmienia nam się zupełnie co otrzymujemy. Dzięki temu zmiana wyglądu strony to kwestia chwili, jak już mamy odpowiednie szablony, bo tylko je zmieniamy nic więcej. Jak zmieni nam się źródło danych to kopiemy w modelu, zachowujemy interfejs i też na modelu się kończy.
Chcemy aby na głównej stronie były dodatkowo ostatnie komentarze, tworzymy (jeśli nie ma) w modelu lastcoment (lub mamy sortowane po dacie i podajemy ile, w ten sposób jest uniwersalne) i w kontrolerze pobieramy, w widoku wyrzucamy, tak na prawdę to tylko kontroler i widok się zmienia (bo w modelu najczęściej mamy odpowiednie metody)

ups, zbyt się rozpisałem

@Sedziwoj

nooooooooo , praktycznie to samo powiedzialem

Pozatym @Sedziwoj,
mysle ze nie ma roznicy jakim typem pliku bedzie widok , ja podalem Smarty + tpl jako pszyklad, chodzi tylko o idee,
Ziels Pamietaj ze do widoku muszą trafic tylko dane(zmienne) które mają byc wyświetlone np.:

<div>Witaj {$LOGIN}</div>

Tak ma być przykładowo zbudowany twój plik tpl w którym umieszczasz tylko zmienne i kod html

w modelu(klasie, tylko kod php) musza byc tylko umieszczone metody które pobieraja odpowiednie dane z bazdy itd. Odnośnie controllera sie nie wypowiem ponieważ ile osób tyle opinii ,
PS. dobrze by było gdybyś dodatkowo stworzył sobie klase obslugujaca baze danych i zainteresował sie np PDO.

Ja to mam tak:

1) Model
Tworze sobie klase ktora generuje dane (lub wstawia je do bazy), takie jak getUserName, getUsersList itd.
Model u mnie korzysta z klas obslugujacych SQL i XML

2) Kontroler
(tak ogolnikowo)
Pobiera dane z wejscia i modelu (ew. przekazuje do modelu) podejmuje na ich podstawie odpowiednie decyzje i przygotowuje dane dla Widoku

3) View
Za View u mnie robi Smarty, do ktorego dane przekazuje Controller (lacznik miedzy Model & View).

BTW: Widok u mnie jest podzielony na glowny (np. glowny layout) i podwidoki do ktorych dane generuja kontrolery, oczywiscie calosc jest tak konfigurowalna (XML) ze mozna ustawiac sobie zadania widokow itd.

Ogolnie to co sobie przeczytalem w necie (i miedzy innymi na php.pl) dalo mi obraz wlasnie tego co wczesniej napisalem. Jedni wchodza w temat szczegolowo - nawet do przesady, czasami bezsensownie rozbijajac wszystko na klasy i konfiguracje - pozniej zeby uruchomic nawet najprostsza aplikacje trzeba edytowac/tworzyc kilkanascie plikow. Inni (tak jak ja) na swoje potrzeby wiele rzeczy upraszczaja (dla mnie model aplikacji WWW jest skonczony - to znaczy w 90% moje rozwiazanie sprawdza sie, nie wazne co robie, czy sklep, cms, intranetowa aplikacje, serwis spolecznosciowy).

Wazne jest zeby Twoj framework spelnial Twoje potrzeby w 100% i dal sie szybko i bezbolesnie rozszerzac i konfigurowac (ale bez przesady!).

A jak zwraca Wam model dane? Tablice asocjacyjne czy tablice objektow? Ja zwracam sobie tablice objektow potem w smartach czy gdziestam sobie to wyswietlam tak $news->tytul. Natomiast zapisuje tak: tworze sobie objekt na przyklad News, napelniam go danymi i wywoluje $model->save($objNews) potem model sobie rozbiera objekt i go zapisuje, nie wiem czy tak jest ok, ten sposob w sumie bardziej sprzega sie model z kontrolerem, z drugiej strony jest wygodniej i ... obiektowo

@NoiseMc
Jak obiektowo to obiektowo, może to zainteresuje: http://www.php.net/~helly/php/ext/spl/
Ważne aby ustalić interfejs wymiany danych.
Zapomnieliśmy i jednym, to kontroler wybiera jaki ma być użyty widok (i używa odpowiednich modeli)

@radzik_w
Nie do końca to samo napisałeś, raczej wszystko zbyłeś jak widok = Smarty, a wcale tak nie musi być.
Właśnie po to robi się te podziały aby móc łatwo wymieniać takie elementy.

Witam was szukałem po sieci ale nic konkretnego na ten temat nie znalazłem ( może zle szukałem ) , ale czy znacie jakieś stronki o mvc albo ksiazki najlepiej po polsku , w ostateczności mogą być ang .Bo znam mvc bardzo podstawowow a bym chcił sie zagłebić i dobrze zrozumieć mvc zeby wykorzystać to w swoich programach / skryptach

Jak wpiszesz MVC w google, to wyrzuci to co trzeba. Nawet na łamach wortalu został swego czasu opublikowany artykuł...

NoiseMC-> mój model zwraca mi tablice - tak dla mnie jest wygodniej, czasami np. w przypadku formularzy dane przychodza w postaci obiektu.