Forum PHP.pl

witam

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




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

Ten post edytował qbal 15.03.2007, 14:34:34

W Ruby on Rails masz wiele kontrolerów i możesz zrobić kontroler na stronę.

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.

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 )
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:

[PHP] pobierz, plaintext 
<?php
class SmartyView
{
	public function render($Data)
	{
		...
		tworzy nowy obiekt Smarty na layoucie o nazwie powiedzmy $Data->params['layoutName']
		...
	   daje Smartiemu zmienne z tablicy $Data->variables
	   ...
	   odpala Smartiego
	}
 
}
?>
[PHP] pobierz, plaintext 

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

[PHP] pobierz, plaintext 
<?php
class XMLView
  {
	  public function render($Data)
	  {
		  ...
		 uruchamia PEAR'owski XMLSerializer->serialize( $Data->variables )
		 ...
		 echuje wynik z odpowienim headerem XML
	  }
 
  }
?>
[PHP] pobierz, plaintext 

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 :

[PHP] pobierz, plaintext 
<?php
class ArticleModel
{
	public function getNewestArticle()
	{
		...
		pobiera najnowszy artykuł z bazy z tablicy Articles (id, author_id, title, body)
		...
	   pobiera nazwe autora z bazy z tablicy  Users za pomocą author_id z artykułu
	   ...
		zwaca array(id,author_id,author_name,title,body)
	}
 
	public function addArticle($author_id, $title, $body)
	{
		...
	   dodaje nowy artykuł do bazy do tablicy Articles (author_id, title, body)
	}
}
?>
[PHP] pobierz, plaintext 

Bardzo fajnie to wymysliles. Ja bym wprowadzil jedna zmiane, mianowicie pozwolil view korzystac z model.

Pozdrawiam

bartek00: Czemu? View powinien korzystac tylko z tego co mu przekaze kontroler. Nic wiecej.

Bartek ma racje
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.

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

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.

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.



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



Wlasnie dlatego view moze korzystac z model.



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

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.

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



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

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 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?

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



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.



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

Ten post edytował bartek00 15.04.2007, 16:40:38

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.

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)