Zalążek frameworka z MVC, Proszę, zweryfikujcie moje podejście Opcje

[Martio]

I dlaczego to, że jakiś framework nie trzyma się zasad MVC, jest wadą?

Oczywiście, że nie jest to wada. I nie uważam, że odejście od wzorca MVC stawia dany framework na gorszej pozycji. Wzorzec ma jedynie ułatwiać pewne sprawy, jednak nie zastosotwanie danego wzorca nie powoduje od razu, że aplikacja jest źle zaprojektowana...

Teraz albo akcja oddaje sterowanie do kontrolera, który dochodzi do wniosku, że należy wykonać odpowiedni widok, lub akcja sama odpala potrzebny widok.

I tutaj jest problem. Jak wykonać to praktycznie? Model zwraca odpowiedź: dodano dane do bazy danych lub nie. I na podstawie tej odpowiedzi kontroler uruchamian kolejną akcję? Jak to wygląda w praktyce (prosty, łatwy przykład w kodzie)?

Muszę się też przyczepić do modelu. Po prostu szał mnie bierze, kiedy widzę $model = new Model(). Model to jest warstwa, a nie klasa. Rysujesz sobie, co aplikacja ma robić, i tworzysz z tego ładny diagram klas, bez żadnego HTTP, HTML, kontrolerów, akcji i całego tego balastu.

Właśnie dzięki takiemu forum jak to mamy możliwość porpawiania swoich błędów i uczyć się od najlepszych.

A więc jak to będzie wyglądało? Co masz na myśli mówiąc wartwa? Model to warstwa czyli metoda klasy kontrolera?

[Vengeance]

Akcja to po prostu część kontrolera. Ponieważ kontroler jest jeden, to zawarcie w tej jednej klasie wszystkich możliwych operacji czyniłoby go strasznie nieczytelnym. Dlatego wydzielono coś co nazwano akcją - i są to najczęśćiej kolejne klasy, odpalane przez kontroler.

Obrazowo, gdyby przyjąć, że akcja to NIE kolejna klasa:

[PHP] pobierz, plaintext 
<?php
class Kontroler
{
   // robi cos waznego, co powtaza sie w kazdym wywolaniu
   // a nastepnie na podstawie $_GET['action'] uruchamia odpowiednia metode
   public function __construct()
   { }
 
   // nasza pierwsza akcja
   public function ShowNews() { }
 
   // nasza druga akcja
   public function DeleteNews() { }
}
?>
[PHP] pobierz, plaintext 

[Martio]

Dobra, ale jak obiektowo w takim bądź razie zakodować łańcuszek akcji. Np. index.php?akcja=news

I teraz są do wykonania akcje:
- sprawdz czy zalogowany
- pobierz newsa
- pobierz dane do menu

I jak bedzie wygladalo to obiektowo?

I pytanko jeszcze: gdzie umiescic informacje czy dostep do newsow ma byc otwarty czy dostepny, po zalogowaniu?

[DeyV]

W takim momencie okazuje, się, że wydzielenie z kontrolera akcji jest bardzo przydatne.
Dlaczego?
Ponieważ to kontoler sprawdza 1 element twojego łańcuszka - tj. czy user jest zalogowany. To on również, po przekonaniu sie, czy akcja, którą user chce wywołać, wymaga logowania, powinien zezwolić na jej załadowanie, lub też wyświetlić okno logowania.

A co robi w tym przypadku "akcja"?
Uruchamia jakąś klasę modelu, która pobiera newsy, i przekazuje ją (lub tylko same dane) do widoku.
To ta akcja musi również pamiętać o załadowaniu danych do menu.
Aby to jednak ułatwić - wiele osob dochodzi do wniosku, że niektóre z elementów strony są wykonywane zawsze, stąd pozwalają akcjom na dziedziczenie po sobie, w celu uruchomienia włąśnie takich elementów jak menu.

A gdzie przehowywywać informację o tym, czy określona akcja ma wymagać autoryzacji? To już Twoja decyzja - większość programistów decyduje sie na przygotowanie plików konfiguracyjnych dla każdej akcji, w których określają takie rzeczy.

[Prph]

No proszę... Najpierw ktoś mówi, że akcja nie steruje, a później inni, że to ona ładuje model i przekazuje dane do wisoku (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

A co do samych metod dostępu.
1. Kontroler ładuje plik konfiguracyjny akcji.
2. Dowiaduje sie z niego, ze akcja wymaga autoryzacji, a co więcej, dostęp mają tylko użytkownicy z grupy Przyjaciele.
3. Kontroler dokonuje autoryzacji - sprawdza czy należymy do Przyjaciele
4. Jak tak, to odpala akcje, jak nie, to jakies inne zdarzenie (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Tak to mniej wiecej wyglada np. w Phiend.

Pozdrawiam.

[DeyV]

Pamiętaj o jednej rzeczy.

MVC nie mówi, jak ma być zbudowany kontoler. Dla tego wzorca ważne jest tylko jedno - zapytania i operacje na danych nie są umieszczane w kodzie html.
Stąd wyraźne rozgraniczenie na model i widok.

Natomiast to, jak tymi 2 elementami będzie zarządzać kontroler, tu już swobodę mają wszyscy.
Przy czym przyznaję, że model kontolera zaproponowany przez Phiend jest w tej chwili jednym z najpopularniejszych, i sprawdza się najlepiej.

Dodam że jego autor, hawk, nazwał go MVCR, gdzie R oznacza router, czyli mechanizm automatycznie zarządzający ładowaniem elementów kontrolera, czyli naszych akcji w oparciu o dane od usera.

[Prph]

No dobrze, a teraz juz troche idac w przyszlosc...
Powiedzmy, ze mam juz moj framework. Index.php wlacza FrontKontroler, on zas wybiera akcje. Ta sobie wczytuje model, wykonuje metode na modelu i dane przekazuje do widoku. Jeszcze w tej samej akcji widok wyswietla dane, czyli do kontrolera nic juz nie wraca.

A tak na tym zbudowac standadowa www? Z naglowkiem, menu i stopka? Moznaby oczywiscie tak:

Kod

--------------------------
        HEAD
--------------------------
                  | menu   |
                  |        |
  Kontroler       |        |
                  |        |
--------------------------
stopka
----------------------------
                    

W srodku wykonałby sie kontroler no i w zasadzie to by jakos zadzialalo. A jak teraz ustawic dynamiczny tytul strony?

A moze tak:

index.php:
1. Kontroler. -> zachowaj dane w widoku w zmiennej np. $BODY.
2. Ustaw menu, title strony
3. Odpal Smarty, zeby zbudowalo strone.

Pozdrawiam,
Adrian.

[eMartio]

Zerknijcie na to. Czeskie, ale myślę, że dobre rozwiązanie:
http://www.zapisky.info/?item=jednoduchy-m...k-napsany-v-php

A tutaj kilka ciekawych artykułów:
http://codesnipers.com/?q=node/156
http://codesnipers.com/?q=node/158
http://codesnipers.com/?q=node/233
http://codesnipers.com/?q=node/239
http://codesnipers.com/?q=node/254

I link dla tych, co nie znają angielskiego:
http://translaticaserv.pwn.pl/cgi-bin/servf.cgi

Ten post edytował eMartio 11.03.2006, 13:38:41

[Martio]

Chciałbym jeszcze powrócić do akcji. Powiedzmy, że nasza aplikacja składa się z takich komponentów:

- publikacje:
-> newsy
-> felietony
-> poradniki

- galeria:
-> sport
-> muzyka

Jak robić to na klasy? Czy dobrym rozwiązaniem jest takie coś:

Wyświetlenie felietonów

[PHP] pobierz, plaintext 
<?php
 
class WyswietlFelieton interface KontrolerAkcji {
  function __construct() {
	$akcja = new Publikacje();
	return $akcja->pokaz('felieton');
  }
}
 
class Publikacje interface Model {
  function pokaz {}
  function edytuj {}
  function dodaj {}
  function usun{}
}
 
class Galeria interface Model {
  function pokaz {}
  function edytuj {}
  function dodaj {}
  function usun{}
}
 
?>
[PHP] pobierz, plaintext 

Kontroler akcji zwraca dane do widoku, który zażądał pobrania danych.

Czy takie rozwiązanie jest prawidłowe? Tworzę sobie wszystkie klasy modelu mojej aplikacji czyli informacje, galerie, forum. Przy uruchamianiu aplikacji pozostaje mi stworzenie kontrolerow.

Akcja to jest jedna czynność. A jak nazywa się zbiór akcji?

Powiedzmy, że kontroler akcji musi zrealizować kilka czynności. Niech będzie zapisanie nowego newsa oraz wyświetlenie pozostałych. Czy to będzie tak wyglądało:

[PHP] pobierz, plaintext 
<?php
 
class ZapiszNewsa interface KontrolerAkcji {
  function __construct() {
	$akcja = new Publikacje();
	$akcja->zapisz('news', $dane);
	return $akcja->pokaz('news');
  }
}
 
?>
[PHP] pobierz, plaintext 

[aleksander]

[PHP] pobierz, plaintext 
<?php
class Kontroler
{
		public function __construct()
		{
				if( isset( $_GET['akcja'] ) )
				{
						$sAkcja = (string)$_GET['akcja'];
				} else {
						$sAkcja = 'defaultowa_akcja';
				}
 
				$oAkcja = new $sAkcja();
				$oAkcja->wykonaj()
		}
}
 
class PokazNewsy
{
		public function wykonaj()
		{
				$oModel = new ModelNewsow();
				$aNewsy = $oModel->pobierzNewsy();
				foreach( $aNewsy as $aNews )
				{
						echo 'tytul: ' . $aNews['tytul']; //itd...
				}
		}
}
 
class ModelNewsow
{
		public function pobierzNewsy()
		{
				return array( array( 'title' => 'przykladowy tytul' ) );
		}
}
?>
[PHP] pobierz, plaintext 

najprostrzy przyklad MVC. Kontroler moze uruchmiac tylko jedna akcje jak chcesz zrobic łańcuch akcji to:

[PHP] pobierz, plaintext 
<?php
class Kontroler
{
		public function __construct()
		{
				if( isset( $_GET['akcja'] ) )
				{
						$sAkcja = (string)$_GET['akcja'];
				} else {
						$sAkcja = 'defaultowa_akcja';
				}
				while( !is_null( $sAkcja ) )
				{
						$oAkcja = new $sAkcja();
						$sAkcja = $oAkcja->wykonaj();
				}
		}
}
 
class PokazNewsy
{
		public function wykonaj()
		{
				$oModel = new ModelNewsow();
				$aNewsy = $oModel->pobierzNewsy();
				foreach( $aNewsy as $aNews )
				{
						echo 'tytul: ' . $aNews['tytul']; //itd...
				}
				return 'nazwa_nastepnej_akcji lub null jezeli akcja ma byc ostatnia';
		}
}
 
class ModelNewsow
{
		public function pobierzNewsy()
		{
				return array( array( 'title' => 'przykladowy tytul' ) );
		}
}
?>
[PHP] pobierz, plaintext 

[Prph]

Ha! A to całkiem ciekawe rozwiązanie.

A jeszcze lekko zmieniając temat - jak przechowywać konfigurację? Globalna tablica, a może zworzec rejestru? Co stosujecie?

Ten post edytował Prph 11.03.2006, 18:03:01

[hwao]

zalezy jakie to dane...

konfiguracja aplikacji define, dane aplikacji czesto rejestr etc.

[Prph]

konfiguracja aplikacji define, dane aplikacji czesto rejestr etc.

dane aplikacji, czyli? Np. konfigi akcji?

[hwao]

konfiguracja aplikacji define, dane aplikacji czesto rejestr etc.

dane aplikacji, czyli? Np. konfigi akcji?

Sciezki, debugowanie pewnych rzeczy etc

[hawk]

[PHP] pobierz, plaintext 
<?php
 
class WyswietlFelieton interface KontrolerAkcji {
  function __construct() {
    $akcja = new Publikacje();
    return $akcja->pokaz('felieton');
  }
}
 
class Publikacje interface Model {
  function pokaz {}
  function edytuj {}
  function dodaj {}
  function usun{}
}
 
class Galeria interface Model {
  function pokaz {}
  function edytuj {}
  function dodaj {}
  function usun{}
}
 
?>
[PHP] pobierz, plaintext 

Nie powinno być interface Model, ani extends Model. Ba, słowo Model nie powinno się w ogóle pojawić w kodzie php. Bo Model to warstwa, tak samo jak Widok. Nie robimy klasy Widok, bo nie wiadomo, co niby miałaby robić. Nie robimy klasy HTML z metodami wyświetlTo(), wyświetlTamto() itd. Tak samo nie robimy klasy Model z wieloma metodami, bo to kolejny przykład god class.

Nie chcę krytykować, bo zaprojektowanie Modelu jest chyba trudniejsze niż sam wzorzec MVC. Np. twoja klasa Publikacje też robi za dużo. Należałoby rozbić to na kontener publikacji, odpowiedzialny za wyszukiwanie (wg. różnych kryteriów) oraz samą klasę Publikacja, odpowiadającej zawsze jednemu rekordowi w bazie danych. Całość należałoby wepchnąć we wzorzec UnitOfWork, w celu zarządzania transakcjami, i dorzucić wzorzec IdentityMap, w celu zapewnienia, że nie będą po aplikacji krążyły dwie instancje klasy Publikacja odpowiadające temu samemu rekordowi. Jak widać, jest to skomplikowane... a jak już się uda to wszystko obiektowo zaprojektować, cały system zaczyna się walić, bo relacyjnej bazy danych nie da się odwzorować za pomocą obiektów. Takie zapytania jak "pokaż tytuły 10 publikacji o największej liczbie komentarzy" lub "usuń wszystkie publikacje starsze niż 1 rok" nie pasują do stworzonej klasy Publikacja.

@Prph: Wyświetlanie "standardowej strony www" z naglówkiem, stopką itd. nie jest wspierane specjalnie przez samo MVC. Generalnie stałe elementy strony przynależą do Widoku. Można dziedziczyć klasy Widoku po jakiejś klasie bazowej, która potrafi wygenerować stałe elementy strony. Można przekazać do instancji klasy Widoku obiekt odpowiedzialny za layout strony, tak, aby obiekt Widoku mógł się "wkleić" w miejsce przeznaczone na content.

A co do konfiguracji, to oczywiście zależy. Najpierw odróżnij konfigurację całej aplikacji (uwierzytelnianie, połączenie z DB, itd) od konfiguracji pojedynczej akcji (np. prawa dostępu). To drugie czasem umieszczane jest w samej akcji (np. stare Mojavi). Najlepiej jest mieć system, który obsługuje różne źródła danych (pliki ini, tablice, XML, itd), wymieniając tylko obiekt odpowiedzialny za wczytywanie pliku z konfiguracją.

[eMartio]

Postanowiłem odejść od wzorca MVC, realizując aplikację wg własnego podziału na 5 warstw. Uważam takie rozwiązanie za najbardziej optymalne w przypadku moich potrzeb.

Warstwa kontroli analizuje żądanie HTTP, następnie tworzy instancję odpowiedniej klasy warstwy poleceń, która realizuje wszystkie zadania w warstwie logiki biznesowej. Wynik przetwarzania trafia do warstwy kontroli, która analizuje dane i uruchamia odpowiedni widok.

W mojej aplikacji warstwa danych będzie zawierała dwie klasy: ObsługaBazyDanych oraz ObsługaPlikuXML. Z tych interfejsów będzie korzystała warstwa logiki biznesowej. Warstwa Logiki Biznesowej będą to klasy modelujące problemy, które system ma rozwiązywać. Np. dodanie nowego użytkownika, sprawdzenie czy login jest wolny, itp.

Warstwa Prezentacji będą to klasy odpowiedzialne za zaprezentowanie danych na zewnątrz systemu czyli html, rss, e-mail, pdf. Warstwa Kontroli może wygenerować więcej niż jedną prezentację, np. wysłanie danych e-mail, wyświetlenie strony WWW.

Warstwa kontroli ma za zadanie, jak sama nazwa wskazuje, kontrolowanie funkcjonowania systemu czyli analizować dane wejściowe i wyjściowe czy pracę warstwy poleceń.

Budowanie nowej aplikacji na bazie mojego frameworka to tworzenie klas warstwy logiki biznesowej, w której będą wszystkie możliwe akcje do wykonania oraz klas warstw poleceń, które inicjują poszczególne metody klas warstw logiki biznesowej. Jedno żądanie HTTP może wymagać zrealizowania kilku zadań (akcji).


(IMG:http://bbmmog.com/bbmmog.png)

Ten post edytował eMartio 12.03.2006, 10:45:35

[Ociu]

Ja podzieliłem sobie kontroler na FrontController i BlockController. Jeżeli framework ma być udostępniony dla innych ludzi, oni sami powinni wybrać jak powinna być zbudowana aplikacja. Dlatego, gdy już wersja będzie dostępna publicznie, tworzę przykładowy FrontController i BlockController. Narzucam jednak metody dla tych klas. Niestety framework, który piszę jest przeznaczony pod php4, więc nie moge skorzystać z interfejsów. Dlatego od tego jest dokumentacja. Tak samo jest z sterownikiem bazy danych i szablonami. Stworzyłem za to klasę ViewRendener, która tworzy klasę View funkcją eval" title="Zobacz w manualu php" target="_manual. Pomógł ten kod wyciągnięty z komentarzy:

[PHP] pobierz, plaintext 
<?php
$clazz = "class SomeClass { var \$value = 'somevalue'; function show() { echo get_class(\$this);}}";
 
eval($clazz);
 
$instance = new SomeClass;
 
// Here output 'somevalue';
echo $instance->value;
 
echo "<br>";
 
//Here output 'someclass'
$instance->show();
?>
[PHP] pobierz, plaintext 

Po modyfikacji wyszło coś takiego:

[PHP] pobierz, plaintext 
<?php
function Render() {
 
			  if( empty( $this->sCore ) ) {
 
				  $error = 'A template system has not been specified';
 
				trigger_error($error, E_USER_ERROR);
 
				return false;
			  }
 
			if( empty( $this->sSystemFile ) ) {
 
				$error = 'A template system files has not been specified';
 
				trigger_error($error, E_USER_ERROR);
 
				return false;  
			}
 
			if( empty( $this->sDir ) ) {
 
				$error = 'A template dir has not been specified';
 
				trigger_error($error, E_USER_ERROR);
 
				return false;  
			}
 
			eval(' class View extends ' . $this->sCore . ' {  } ');
 
			$oView = new View;
 
			return $oView;
 
		}
?>
[PHP] pobierz, plaintext 

Cały schemat aplikacji wygląda mniej więcej tak (wraz z przykłądowym FrontControllerem):
Controller -> tworzenie obiektu Services, który zawiera obiekty HttpRequest i User -> Controller przekazuje dane do FrontControllera -> FrontController sprwadza w ActionChain czy dana akcja jest zdefiniowana -> pobieranie configa i sprawdzanie w User czy dany użytkownik ma prawo korzystać z akcji - Tak: Akcja jest uruchamiana, która uruchamia model, przekazując wynik danych z modelu do widoku; Nie: wyrzucana jest strona z błędem. -> FrontController przekazuje wynik akcji do Kontroler głownego, który tworzy stronę tak:

[PHP] pobierz, plaintext 
<?php
function compose () {
 
			$config = new Config;
			$config->initialize('Main');
 
			$layer = $this->view->Render();
 
 
			$layer->assign('Title', $config->get('site_title'));
 
			$layer->assign('MenuLeft', $this->Controllers['BlockController']->getRightSide());
			$layer->assign('MenuRight', $this->Controllers['BlockController']->getLeftSide());
 
			$layer->assign('content', $this->Controllers['FrontController']->run());
 
			$layer->parse('index.tpl');
 
		}
?>
[PHP] pobierz, plaintext 

pozdrawiam

[eMartio]

Analizując wszystkie wątki o MVC na tym forum zgłupiałem! Jedni twierdzą, że X rozwiązanie jest prawidłowe, inni zaś, że kłuci się to z wzorcem MVC. Są na tym forum znakomici programiści, którzy stworzyli całkiem niezłe frameworki oparte na tym wzorcu. Mam do Was wielką prośbę. Czy możecie zrobić malutkie podsumowanie poprzez odpowiedz na poniższe pytania:

1. Co to jest akcja, gdzie się ją implementuje?
2. Co to jest łańcuszek akcji, gdzie się go implementuje?
3. Czy wartswa logiki biznesowej należy do modelu? Są dwie klasy: jedna odpowiedzialna za obsługę plików xml (odczyt, zapis, edycja), druga klasa za akcji: zapisanie danych z formularza $_POST w pliku XML (korzystając z klasy do obsługi pliku). Czy obie te klasy to model?
4. Jak należy zbudować aplikacje wg zasady: jak najmniej kodu? Jedna stała, uniwersalna klasa dla kontrolera, kilka klas modelu ze wszystkimi możliwymi operacjami, kilka klas widoku. I teraz jak na podstawie np. linku domena.pl/news.php wykonac nastepujace czynnosci: pokazac wszystkie newsy z dnia dzisiejszego (klasa: news, metoda: pokaz), usunac wszystkie z dni poprzednich (klasa: news, metoda: usun), pokazac wszystkie komentarze (klasa: komentarz, metoda: pokaz). Skad system ma wiedziec, ze na podstawie krotkiej informacji pobranej z URL 'news' ma wykonac 3 zadania (X zadan i jakie to zadania)?

Prosze o precyzyjna odpowiedz. Po przeczytaniu wszystkich watkow o MVC na tym forum juz calkowicie zglupialem (IMG:http://forum.php.pl/style_emoticons/default/sad.gif)

[Vengeance]

"Czy możecie zrobić malutkie podsumowanie"
Nie nie możemy. Dlaczego?
Wzorzec obiektowy zawsze pozostanie wzorcem, schematem....
a wszystkie rozwiązania przedstawione w tym i innym wątku to implementacje. Każda jest inna, ale nie ma lepszych i gorszych.

Dlatego nie patrz na to, jak inni rozwiązują daną kwestie bo rzeczywiście zgłupiejesz! Znasz podstawowe zasady rządzące danym wzorcem, teraz pomyśl nad własną implementacją. Przecież, gdybyś miał robić tak jak ktoś inny, a nie tak jak Ci wygodnie to po co pisać na nowo - lepiej wykorzystać gotowe rozwiązanie.

Także to czy jest akcja, czy jest klasą czy metodą, czy kontrolery są bardziej rozproszone oraz jak działa widok/model to implementacja. MVC mówi tylko o tym, że mają być 3 warstwy (tak samo jak cebula ma warstwy i tort ma warstwy - ogry też je mają i MVC również. Ale MVC nie jest jak ciasto z kremem) ;P

[hawk]

MVC mówi tylko o tym, że mają być 3 warstwy (tak samo jak cebula ma warstwy i tort ma warstwy - ogry też je mają i MVC również. Ale MVC nie jest jak ciasto z kremem) ;P

Kremówki to jednakowoż jedno z najlepszych ciastek; ja to wiem!