Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: czy moj model to MVC?
Forum PHP.pl > Forum > PHP > Object-oriented programming
qbal
witam

Mam pytanie czy taki model aplikacji jak podalem ponizej moge uznac za model MVC?


Kod
       MODEL         |                                kontroler                                        |     widok
---------------------|---------------------------------------------------------------------------------|-------------------            
baza danych <--> DBO |<--> klasy przetwarzajace dane z bazy <-->| pliki poszczegolnych podstron serwisu|<--> szablony Samrty
                     |                                          | obsluguja one zadania GET i POST     |


w typowym MVC powinien byc jeden kontroler. Ja mam osobne dla kazdej strony np. osobne dla index.php, osobne dla przegladania artykulow, osobne dla dodawania artykulow. kazde przetwazaja parametry GET i POST, SESSION tylko w obrebie swojej strony, oraz wywoluja klasy do pobrania i przetworzenia danych z bazy
Kayne
W Ruby on Rails masz wiele kontrolerów i możesz zrobić kontroler na stronę.
Sh4dow
Nie wiem co ludzie maja z tym porownywaniem do RoR no ale nie i to chodzi.

Sposobow na kontrolery jest wiele. Mozesz miec jeden duzy, mozesz miec jeden na strone, a mozesz miec takze jeden glowny ktory kieruje na kontroler danej strony/modulu/paczki (zwał jak zwał). Wszystko w zaleznosci od tego jak zaprojektujesz aplikacje. Jesli odwolujesz sie do wielu plikow przy wielu stronach to nie zastosujesz tej samej konstrukcji kontrolera jak przy aplikacji z jednym glownym plikiem i parametrami dla wielu stron.
domis86
Ja proponowałbym tak:

mamy:
-jeden FrontController - index.php
-wiele Controller'ów
-wiele Modeli
-wiele View'ów


działanie FrontControllera:
1.wszystkie linki idą na FrontController i on decyduje który Controller i którą funkcje - czyli akcje - w nim odpalić ( i odpala aarambo.gif )
2.po zakończeniu się akcji zwraca ona jakies dane (powiedzmy obiekt Data), ktore FrontController odbiera
3.w Data->viewName zapisana jest nazwa View'a, który ma być odpalony. FrontController odpala ten View i przekazuje mu wspomniany już obiekt Data.
4.po zakończeniu się View'a jest koniec programu.

działanie Controller'a:
1.zaczyna działac gdy FrontController go stworzy i odpali jakąś jego funkcje
2.cos robi. Moze korzystac z POST i GET i z Modeli
3.Modele musi sobie zaladowac w zaleznosci od swoich potrzeb.
4.nie moze nic wypisywac(zadnych echo, print etc) ani korzystac z bazy danych,plikow i zrodel danych innych niz Modele
5.akcja musi zwrócic obiekt Data zawierający viewName i dane do wyswietlenia.

dzialanie View'a:
1.odpala go FrontController.
2.bierze dane z obiektu Data i wysietla je odpowiednio.
3.moze korzystac TYLKO z obiektu Data - zadnych modeli, controllerow, bazy danych, GET, POST itp

przyklad View'a który wyswietla strone HTML za pomocą Smarty:

  1. <?php
  2. class SmartyView
  3. {
  4. public function render($Data)
  5. {
  6. ...
  7. tworzy nowy obiekt Smarty na layoucie o nazwie powiedzmy $Data->params['layoutName']
  8. ...
  9.  daje Smartiemu zmienne z tablicy $Data->variables
  10.  ...
  11.  odpala Smartiego
  12. }
  13.  
  14. }
  15. ?>



przyklad View'a który wyswietla dane w postaci XML:

  1. <?php
  2. class XMLView
  3. {
  4. public function render($Data)
  5. {
  6. ...
  7.  uruchamia PEAR'owski XMLSerializer->serialize( $Data->variables )
  8.  ...
  9.  echuje wynik z odpowienim headerem XML
  10. }
  11.  
  12. }
  13. ?>



działanie Modelu:
1.uzywany przez Controllery.
2.Jest posrednikiem miedzy zrodlem danych a Controllerem.
3.pobiera dane z np bazydanych i daje je w odpowiedniej formie Controllerowi
4.zmienia dane w bazie za poleceniem Controllera - moze je tez walidować.

przyklad Modelu :

  1. <?php
  2. class ArticleModel
  3. {
  4. public function getNewestArticle()
  5. {
  6. ...
  7. pobiera najnowszy artykuł z bazy z tablicy Articles (id, author_id, title, body)
  8. ...
  9.  pobiera nazwe autora z bazy z tablicy Users za pomocą author_id z artykułu
  10.  ...
  11. zwaca array(id,author_id,author_name,title,body)
  12. }
  13.  
  14. public function addArticle($author_id, $title, $body)
  15. {
  16. ...
  17.  dodaje nowy artykuł do bazy do tablicy Articles (author_id, title, body)
  18. }
  19. }
  20. ?>
bartek00
Bardzo fajnie to wymysliles. Ja bym wprowadzil jedna zmiane, mianowicie pozwolil view korzystac z model.

Pozdrawiam
menic
bartek00: Czemu? View powinien korzystac tylko z tego co mu przekaze kontroler. Nic wiecej.
domis86
Bartek ma racje smile.gif
Od czasu kiedy pisałem tamten post zewoluowalem, i teraz wiem, ze w MVC View ma korzystac z Modeli.

1.Controller decyduje który View ma sie wyswietlac.
2.Front Controller uruchamia odpowiedni View i ten View pobiera sobie wszystkie dane z Modeli i wysietla sobie.
menic
A ja sie nie zgadzam. Widok moze pobrac tylko to na co mu kontroler pozwoli. Nie moze mieć wolnej reki co do wyboru. Ma miec z góry okreslone ze może miec to i tamto. KONIEC winksmiley.jpg
Sedziwoj
Ja się zgodzę z menic, bo ma być rozdzielenie przecież widoku od reszt, więc ma wiedzieć że dostaje takie dane i je formatuje, a kontroler ma się kontaktować z modelami.
Aby jak struktura aplikacji ulegnie zmianie widoki nie musiały, bo chyba do tego dążymy aby części działały niezależnie, a MVC to jest jedna z druk, która na pewno się rozwinie. Już teraz przecież już teraz izolujemy kontroler od struktury danych, aby jak ta się zmieni to modyfikujemy modele i tyle, reszta sobie dalej działa.

Czyli widok powinien mieć dostęp tylko do tego co przekaże kontroler.
bartek00
Wedlug mnie idea view polega na tym aby wiedzial skad pobierac dane i je w odpowiedni swoj wlasny sposob wyswietlac. Jesli dane, to pobierane z model. Ingerencja controller ogranicza sie tylko do wydawania rozkazow dla view w jaki sposob, a nie skad pobierac te dane.

Cytat
A ja sie nie zgadzam. Widok moze pobrac tylko to na co mu kontroler pozwoli. Nie moze mieć wolnej reki co do wyboru.


Tutaj sie nic nie zmienia. To controller steruje, wydajac rozkazy, tym w jaki sposob view ma pobierac dane. Nie oznacza to ze ma wskazywac za kazdym razem zrodlo tych danych (model).

Cytat
Ma miec z góry okreslone ze może miec to i tamto. KONIEC


Wlasnie dlatego view moze korzystac z model.

Cytat
Aby jak struktura aplikacji ulegnie zmianie widoki nie musiały, bo chyba do tego dążymy aby części działały niezależnie, a MVC to jest jedna z druk, która na pewno się rozwinie. Już teraz przecież już teraz izolujemy kontroler od struktury danych, aby jak ta się zmieni to modyfikujemy modele i tyle, reszta sobie dalej działa.


Przeciez w tej kwestii nic sie nie zmienilo.


Poza tym istnieje linia pomiedzy dwoma etapami aplikacji : logika oraz wyglad. Podczas pierwszego etapu uruchamia sie controller, ktory moze zmieniac, dodawac, usuwac dane, wtedy wykorzystuje do tego zadania modele. Gdy caly proces sie zakonczy ustawia odpowiedni view, ktory ma wyswietlic dane. I teraz czy jest potrzeba obciazania controller w fazie logiki aby pbieral dane z modelu i przekazywal je do view ? Wedlug mnie w tym momencie konczy sie logika i zaczyna sie wyglad. Uruchamia sie view i on bezposrednio z zrodla danych (model) pobiera dane do wyswietlania. Wyswietla je. Koniec.

Pozdrawiam
Sedziwoj
Cytat(bartek00 @ 15.04.2007, 09:10:36 ) *
Przeciez w tej kwestii nic sie nie zmienilo.


A właśnie że tak, bo przy zmianie modeli musisz zmienić widoki, a widoki moim zdaniem powinny być zmieniane jedynie przy zmianie kontrolera.
Do tego jak wystąpi błąd przy pobieraniu danych z modelu, to w przypadku kiedy to kontroler go obsługuje, można zmienić z jakiego widoku będzie się korzystało.
bartek00
Cytat
A właśnie że tak, bo przy zmianie modeli musisz zmienić widoki, a widoki moim zdaniem powinny być zmieniane jedynie przy zmianie kontrolera.


Przy zmianie modeli ? Na tym wlasnie polega cala idea, ze jak musze zmienic model to nie ruszam ani view ani controller.

Cytat
Do tego jak wystąpi błąd przy pobieraniu danych z modelu, to w przypadku kiedy to kontroler go obsługuje, można zmienić z jakiego widoku będzie się korzystało.


Mam rozumiec, ze jak masz strone gdzie listuje sie, nie wiem, adminow to w przypadku bledu danych zmieniasz widok i wypisujesz wielkimi czerwonymi literami ze np. baza nie dziala ? Ja wole wypisac komunikat w miejsce gdzie miala byc wypisana lista adminow, w tym samym view.

Pozdrawiam
menic
bartek00: co do tego przykladu z adminami... W przypadku błedu, który wyłapie w kontrolerze wole zmienic widok na jakis defaultowy bledu i jako parametr dac mu tresc błedu...
Sedziwoj
Cytat(bartek00 @ 15.04.2007, 10:13:21 ) *
Przy zmianie modeli ? Na tym wlasnie polega cala idea, ze jak musze zmienic model to nie ruszam ani view ani controller.


nie to że struktura danych się zmieni, tylko konstrukcja relacji między kontrolerami a modelami, czyli przy reorganizacji modeli (bo przy rozbudowie serwisu może się zdarzyć) i wtedy jak jakiś widok korzysta z modelu bezpośrednio i ten model jest właśnie zmieniany, to widok też musi być poprawiony, a chyba nie o to chodzi?
bartek00
Wedlug mnie glowny problem polega na tym, ze probujecie w swojej wyobrazni skonfrontowac pomysl z korzystaniem przez view z model ze sposobem dzialania framework (na podstawie MVC), na ktorym pracujecie.
Drugim problemem jest to, ze nie staracie sie znalezc pozytywow tego rozwiazania (moze dlatego, ze nie chcecie miec zmieszania co jest poprawne, a co nie).

Cytat
bartek00: co do tego przykladu z adminami... W przypadku błedu, który wyłapie w kontrolerze wole zmienic widok na jakis defaultowy bledu i jako parametr dac mu tresc błedu...


Nie widze przeszkody, aby rozwiazac to w ten sposob (tylko nie piszcie, ze sie nie da poniewaz nie da sie tego zrobic w jakims tam framework). Kwestia gustu.

Cytat
nie to że struktura danych się zmieni, tylko konstrukcja relacji między kontrolerami a modelami, czyli przy reorganizacji modeli (bo przy rozbudowie serwisu może się zdarzyć) i wtedy jak jakiś widok korzysta z modelu bezpośrednio i ten model jest właśnie zmieniany, to widok też musi być poprawiony, a chyba nie o to chodzi?


Dlugo sie zastanawialem nad odpowiedzia na temat twojej wypowiedzi cytowanej wyzej, Sedziwoj. Naprawde nie wiem jak mam sie do tego ustosunkowac, a chcialbym do kazdej wypowiedzi w tym temacie. Zmiany o ktorych mowisz wydaja sie fundamentalne. Jesli sa takie wymagane podczas rozbudowywania serwisu to chyba bylo cos zle zaplanowane u samych podstaw. Moze sie zle zrozumielismy.

Pozdrawiam
Sedziwoj
bartek00 wiesz jak my nie widzimy pozytywnych aspektów tego aby widok miał dostęp do modeli, a Ty je widzisz, to je nam przedstaw. Byłbym wdzięczny, bo może czegoś po prostu nie widzę.

Co do rozbudowy, nie świadczy że projekt był zły. Ponieważ nie jesteś w stanie przewidzieć wszystkich możliwości. Do tego widok, powinien jedynie 'ubierać' informacje w pewną formę, ale po co ma pobierać samodzielnie coś?

Więc napisz, jakieś przykłady (abstrakcyjne, czy też bardziej rzeczowe) kiedy jest potrzeba aby widok korzystał z modelu.

P.S. Wiedziałem, że mój przykład będzie podchodził pod zły projekt, ale nie miałem chwilowo pomysłu na lepszy, oprócz wyświetlania komunikatów błędu.
Reigon
Cytat(bartek00 @ 15.04.2007, 08:13:21 ) *
Ja wole wypisac komunikat w miejsce gdzie miala byc wypisana lista adminow, w tym samym view.


Tez tak to robie, dokladnie ustawiam zmienna na true (error lub komunikat) i jezeli jest true to laduje tablice z wiadomosciami... Jezeli zaladujesz domyslny widok, to nie masz mozliwosci np. poprawienia danych w formularzu na tej samej stronie.

Odnosnie problemu z modelem. Ja jestem za rozwiazaniem, aby jednak View korzystal tylko z okreslonego obiektu - kontenera (w ktoryms z artykulow okreslony byl mianem ModelAndView) ktory dostarcza tablice z danymi do renderowania (zastanawiam sie, czy nie przekazywac obiektu zamiast tablicy, ale dla renderowania danych i ze wzgledu na szybkosc tablica bedzie chyba lepsza) niz z wielu modeli.

No i u mnie akurat controller (akcji) wybiera (ustawia) widok, a front controller go uruchamia (kaze sie renderowac)
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.