Otóż ostatnio mam problem. Postanowiłem, że podczas uruchamiania aplikacji do dyspozytora jest przekazywana path do modelów i kontrolerów. Otóż mam mały problem. Doskonale wie każdy do czego to służy. Jednak problem tkwi co ten model musi zawierać jakie funkcje? Jak też przekazywać obiekt dostępu do bazy danych w aplikacji
EDIT///
Zrobiłem rejestr systemowy frameworka. Zawierać będzie ten głupi DB object ....

Wiele osob pyta o model.

Model nie musi zawierac zadnych ustalonych metod! Jest to bardzo wazne.
Model nie jest czyms standardowym, tak jak kontroler, a tym bardzi jak widok. Widok wiemy do czego sluzy - wyswietla nam dane. Nie pobiera ich z bazy, nie wysyla nam maili. On tylko wyswietla (z czym wiaze sie kilka metod).

Model natomiast moze byc naprawde rozny. Moze pobierac/zapisywac dane z bazy, plikow XML, albo z innego serwera. Co da Ci nakazanie kaZdemu modelowi metody run, execute albo cos innego? nic!

Np model nowos moze miec metody: show, save, getTitle itp.

I oczywiscie, zeby wygodnie sie programowala to model moze dziedziczyc z jakiesgos bazowego, ktoru ma juz ustalone np polaczenie z baza danych.

Adrian.

No właśnie teraz na to wpadłem . Po prostu wrzucę to przy pomocy rejestru i konstruktor te podstawowe narędzia dla modelu...

W jednym temacie na tym forum pisałem, że chcę narzucić wszystkim klasom, które pełnią rolę modelu jednakowe metody za pośrednictwem interfejsu i się na tym nieźle przejechałem . Na dłuższą metę staje się to bardzo niewygodne. Lepiej jest stworzyć więcej interfejsów oddzielnych dla poszczególnych modeli i mieć spokój. Jak Prph wspomniał, nie ma sensu tworzyć uniwersalnego modelu. Można conajwyżej stworzyć klasę zawierającą jakieś metody, z których korzystają wszystkie modele i te modele będą z niej dziedziczyć.

@Speedy dobrze prawisz. Ja bym tylko nie dawal tych interfejsow. To znaczy nie widze zadnego sensu. Ale pomysl np. z metoda getDB() ktora zwraca nam obiekt bazy jest nak najbradziej wygodny

Adrian.

Ja, zamiast getDB(), preferuję w konstruktorze klasy, po której dziedziczą wszystkie klasy modelu, zapamiętać referencję do klasy obsługującej szablony albo kontrolera. Przykładowo:

[PHP] pobierz, plaintext 
<?php
public function __construct()
{
	$this -> application = Application::GetInstance();
	$this -> tpl = $this -> application -> tpl;
	$this -> some_class = $this -> application -> some_class;
}
?>
[PHP] pobierz, plaintext 

Dzięki temu nigdzie wewnątrz klasy modelu nie muszę wywoływać ::GetInstance(), gdyż mam to rozwiązane dużo wygodniej.

Szablon w modelu?
Poza tym... majac na mysli getDB() mialem na mysli metode modelu. Czyli to samo co proponujesz Ty. Kod:

[PHP] pobierz, plaintext 
<?php
class Opt_Model_MySQL
{
  public function __construct()
  {
	$aParameters = array
	(
	  'host'	 => 'localhost',
	  'user'	 => '',
	  'password' => '',
	  'database' => ''
	);
 
	$this->_oDatabase = new Rapide_Database_MySQL($aParameters, true);
  }
 
  public function getDB()
  {
	return $this->_oDatabase;
  }
}
?>
[PHP] pobierz, plaintext 

Fakt, zbytnio pospieszyłem się z tym modelem i szablonami. Oczywiście chodziło mi o klasę, po której dziedziczą wszystkie klasy akcji, a nie modelu. Przykład: repozytrium mojego projektu Aedo - wszelkie akcje umieszczone w /core/modules/ dziedziczą po klasie /core/lib/class.Actions.php, dzięki czemu po otrzymaniu danych z modelu nie muszą wywoływać żadnych wzorców typu singleton. Bardzo przyjemne i przejrzyste rozwiązanie, polecam.

Dobrze ja jednak zamiast getDB wolę . W konstruktorze.
$this->db = registry('db');
I voilla....