MVC od strony praktycznej Opcje

[eMartio]

O MVC na tym forum i w publikacjach elektronicznych oraz tradycyjnych napisano juz wiele. Jednak co publikacja, to nowa implementacji wzorca MVC. Widzialem juz projekt, w ktorym pobranie danych odbywalo sie w kontrolerze, a w modelu jedynie ich przechowywanie.

Mam taki problem. Nigdzie nie moge doczytac czy wzorzec MVC bierze cos takiego pod uwage, jak kilka modeli i widokow? Wiem, ze kontrolerow moze byc kilka. A co z modelami i widokami? I jak to zakodowac obietkowo?

Problem: na podstawie url: index.php?akcja=newsy kontroler wybiera model Newsy, w ktorym pobierane sa wiadomosci z bazy danych. Nastepnie zostaja przeslane do dwoch widokow. Pierwszy to widok 'xml', ktory w ktorym generuje plik kanalu rss, a drugi widok to 'http', ktory uruchamia szablon Smarty z newsami.

Jak to zakodowac obiektowo? Czy tak jak zademonstrowalem to ponizej?

[PHP] pobierz, plaintext 
<?php
index.php?akcja=newsy
 
class Kontroler {
  public $akcja;
  public $model;
  public $view;
 
  public constructor($a) {
    $this->akcja = $a;
  }
  public model($typ) {
    // typ = mysql, xml
    $nazwa_klasy = 'Model'.$this->akcja;
    return $dane = new $nazwa_klasy($sekcja);
  }
  public widok($typ) {
    // typ = html, xml
    $nazwa_klasy = 'Model'.$this->akcja;
    return $dane = new $nazwa_klasy($typ, $dane = $this->model);
  }
}
 
$mvc = new Kontroler($_GET['a']);
$mvc->model(mysql);
$mvc->widok(xml);
$mvc->widok(html);
?>
[PHP] pobierz, plaintext 

(IMG:http://forum.php.pl/uwaga.gif)
poprawiam
trzecie upomnienie. za czwartym będzie ostrzeżenie
---
nospor


I od razu nasuwaja sie pytania:
1. Jak zrobic, aby liczba widokow byla generowana dynamicznie (nie zawsze beda 2 widoki, moze byc 1,2,3 lub wiecej widokow)
2. Jak skonstruowac klase akcji?
3. Czy jedna akcja to pobranie modelu i przkazanie go widokowi? A raczej, to widok sobie pobiera model.
4. Co z danymi przeslanymi z formularza? Trafia do modelu i zostaje dopisane do bazy danych lub pliku xml; widok nie jest potrzebny.

[Speedy]

eMartio: Wydaje mi się, że za bardzo kombinujesz z tymi szablonami.

Mam na myśli to:

[PHP] pobierz, plaintext 
<?php
 
// [...]
 
public function uruchom() {
	if (file_exists('templates/'.$this->sekcja.'/'.$this->akcja.'.mod.tpl')) {
	  $this->smarty->assign('modul', $this->sekcja.'/'.$this->akcja.'.mod.tpl');
	  $this->smarty->assign('dane', $this->dane);
	  $this->smarty->display($this->sekcja.'/index.tpl');
	} else {
	  throw new Exception('Brak wymaganego szablonu.');
	}
  }
 
// [...]
 
?>
[PHP] pobierz, plaintext 

Nie wiem, z jakiego systemu szablonów korzystasz, ale np. za pomocą Smarty można pominąć te ambarasy (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) .

Można zrobić np. tak:

[PHP] pobierz, plaintext 
<?php
 
	if($option == '')
	{
	$option		= 'news';
	$category		= '1';
	$id			 = 'page';
	$current_page = '0';
	}
 
$site = $action->site($option,$category,$id,$current_page); 
 
$core->smarty->assign("array",$site);
 
?>
[PHP] pobierz, plaintext 

Idea jest taka, że na podstawie zmiennych przekazywanych w adresie pobierasz za pomocą metody $action->site() tablicę z odpowiednimi danymi, a w szablonie Smarty są instrukcje wyświetlające odpowiednie dane, gdzie każda tablica siedzi w zmiennej $array i jest generowana w zależności od podanych parametrów, które są np. w adresie strony.
Inkludować pliki *.tpl też możesz w samym szablonie.
Na dobrą sprawę nie wiem, jak masz zorganizowane to wszystko u siebie, ale na pierwszy rzut oka wydaje mi się ten fragment kodu przekombinowany (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) .
(właściwe to w moim przykładzie zmienna $site pełni funkcję zmiennej $this->dane w Twoim przykładzie).

Zgodzę się, że przypadku jakichś specyficznych danych typu PDF jest sens tworzenia klasy widoku, aczkolwiek, jak już wcześniej przedmówcy wspomnieli, w przypadku danych typu html lub xml, jest to bez sensu.

A kto mówi, że sposób który opisałeś to nie MVC? :] Sam twierdzisz, że rozdzielasz kod na akcje (add/del/edit) i wydzilasz także odpowiednie metody pobierania danych (model) jak i metody do ich wyświetlenia (view).

Ale teorytycznie nie jest to czysty MVC (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) , gdyż mam w jednej klasie metody do modyfikacji danych i ich pobierania (czyli model+kontroler i do tego rozproszone), a wydaje mi się, że MVC rozgranicza te dwie sprawy (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) . Po prostu w niektórych sytuacjach, gdzie musiałem wykonywać operacje na różnych danych, ładowanie wszystkich metod pobierających dane w jedno miejsce i wszystkich metod modyfikujących je w inne miejsce, wydało mi się czymś, co może spowodować bałagan. Moje założenia czerpią trochę z MVC, lecz nie kopiują go w pierwotnej formie. Nietrudno można dojść do wniosku, że nie ma sensu sztywno stosować idei modelu widoku i kontrolera. Czasem lepiej trochę ją nagiąć i zmodyfikować w celu usprawnienia działania aplikacji oraz dla zachowania porządku w projekcie (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) .