[MVC] Czy dobrze interpretuję ?, ciągle to mvc :( Opcje

[matix]

Witam,

Ciągle zastanawiam się, czy dobrze interpretuję zasadę MVC.

Chciałem napisać coś takiego:

KONTROLLER: Index.Controller.php:

Pobiera $_GET['view'] i zwraca $this -> setView():

[PHP] pobierz, plaintext 
<?
class aController 
{
  private $sView;
 
		function __construct() 
	{
		$this -> sView = $_GET['view'];
				self::setView();
	}
 
 
	function setView()
	{
		require_once('view/'.$sView);
	}
}
?>
[PHP] pobierz, plaintext 

Następnie MODEL pobiera dane z mysql z danego projektu i zwraca:

[PHP] pobierz, plaintext 
<?
class db 
{
	function __get() {
		while (...) 
		{
			$oArray[] = $db -> id;
		}
 
		return $oArray;
	}
 
}
?>
[PHP] pobierz, plaintext 

W ostateczności Widok pobiera wszystko i generuje HTML:

[HTML] pobierz, plaintext 
Klient o ID: <?=$db['id'];?><br/>
Pobrał .... <?=$db['nazwa'];?>
 
To jest przykładowa tresc pliku widoku.
[HTML] pobierz, plaintext 

Męczy mnie także pytanie, jak to wszystko połączyć, zeby działało?
Chodzi o większą ilość widoków, lub modeli.

Proszę mnie nie odsyłać do artykułów, bo z nich nic się (niestety) nie można dowiedzieć.

Pozdrawiam, Matix: )

Ten post edytował matix 25.05.2007, 22:03:54

[Ludvik]

Akcja wykonkuje operację na modelu po czym zwraca odpowiedni obiekt widoku.

Tak być nie powinno. Akcja nie ma prawa być powiązana w żaden sposób z obiektem widoku. MVC polega na oddzieleniu od siebie tych trzech warstw, więc wprowadzanie zależności pomiędzy modelem a widokiem łamie podstawowe zasady tego wzorca. Zmiana widoku spowoduje katastrofę w klasach akcji... Model powinien zwracać kontener z danymi, który następnie zostanie przekazany do widoku, tak aby nie były tworzone powiązania pomiędzy warstwami.

Sam pracuję w tej chwili nad implementacją MVC. Kontroler u mnie integruje całą aplikację, posiada wymienne Dispatchery, które tłumaczą żądanie HTTP na żądanie wykonania łańcucha akcji. Przed wykonaniem łańcucha, żądanie musi przejść przez filtry, w których np. można umieścić autentykację i autoryzację. Następnie kontroler iteruje przez kolekcję obiektów wywołujących akcje (czyli po prostu wykonuje kolejne akcje z łańcucha). W razie zmiany łańcucha, zostaje o tym poinformowany kontroler, który w razie czego wróci na jego początek. Kwestia implementacji obserwatora. Nad widokiem jeszcze myślę, gdzieś to upchnę po łańcuchu akcji... Dane są przesyłane w odpowiednich obiektach pomiędzy akcjami. W obiekcie kontekstu można zapisać informacje dotyczące całego żądania, czyli stan sesji itp...