moze głupie pytanie, ale wszystkie moje pliki model wyglądają tak samo, czyli

[PHP] pobierz, plaintext 
<?php
 
class nazwa_klasy extends Zend_Db_Table {
   protected $_name = 'nazwa_tabeli';
 
 
}
?>
[PHP] pobierz, plaintext 

W jakich przypadkach bede musiała coś tu dodawać ?

ZF nie narzuca sztywnego modelu. Nie jestem super biegły w ZF, bo dopiero od niedawna się go uczę, ale pochodne klasy Zend_Db_Table służą tylko jako akcesor do danych z bazy danych. Możesz sobie zrobić dwie (lub trzy - taki jest przykład w dokumentacji) hierarchie klas, gdzie jedna będzie rozszerzała Zend_Db_Table (dostęp do bazy danych), a druga (klasę bazową możesz sobie napisać sama) będzie te dane heremtyzowała.

Ja jak narazie korzystam z 3 równoległych hierarchi klas, przykładowo:

[PHP] pobierz, plaintext 
<?php
class Model_DbTable_Article extends Zend_Db_Table{
  $_name = 'article';
}
 
class Model_Mapper_Article{
  private $dbTable;
 
  public function __construct(){
    $this->dbTable = new Model_DbTable_Article();
  }
 
  /**
   * @return array Tablica obiektów Model_Article
   */
  public function fetchAll($select){
    //wyszukiwanie danych za pomocą $this->dbTable
    //oraz załadowanie danych do obiektów Model_Article
  }
 
  /**
   * @return Model_Article
   */
  public function findOne($pk){
    //..
  }
 
  /* inne metody, np. save, delete */
}
 
class Model_Article{
  private $data = array();
  private $fields = array('id', 'title', 'content');
  private $mapper;
 
  public function __construct($data = array()){
    $this->data = $data;
    $this->mapper = new Model_Mapper_Article();
  }
 
  public function __get($name){
    //sprawdzenie czy istnieje $this->fields[$name]
    //ewentualnie sprawdzenie czy istnieje metoda 'get'.$name i jej wywołanie
    return $this->data[$name];
  }
 
  public function __set($name, $value){
    //sprawdzenie czy istnieje $this->fields[$name]
    //ewentualnie sprawdzenie czy istnieje metoda 'set'.$name i jej wywołanie
    $this->data[$name] = $value;
  }
 
  public function save(){
    $this->mapper->save($this);
  }
}
?>
[PHP] pobierz, plaintext 

Metody (fetchAll, find itp) klasy rozszerzająca Zend_Db_Table zwracają obiekty Rowset lub Row. Klasa mapper ma podobne metody co klasa tabeli, ale zwraca obiekty modelu Model_*, które to przechowują dane - czyli implementacja wzorca DAO.

Linki do manuala
http://framework.zend.com/manual/en/zend.d...ationships.html
http://framework.zend.com/docs/quickstart/...-database-table

osobiście nie potrafię ugryźć mappera, ogólnie mało o tym piszą chociaż szukałem sporo. Peter czy mógłbyś podać jakiś inny pełny przykład takiego mapowania, który by mi bardziej otworzył oczy na ten wzorzec?

Czy jest sens w ogóle nakładać tyle warstw na model? Przecież metody Model_Article można by śmiało umieścić w Model_DbTable_Article z ominięciem mapera (?) Niech mnie ktoś oświeci.

Tak jak napisałem, nie jest konieczna klasa mappera, jego funkcjonalność można przenieść na klasę tabeli rozszerzając odpowiednie metody.

Można to tak zrobić, że jedna hierarchia klas w modelu (ta która dziedziczy po table) wydobywa informacje z bazy danych, tworzy właściwe obiektu modelu i je zwraca. Druga hierarchia klas to klasy hermetyzujące dane z bazy danych - posiadają metody get/set do pobierania/ustawienia wartości poszczególnych pól (przykładowo kolumn z bazy danych, ale nie koniecznie). Dane (czyli ta warstwa która nie dziedziczy po table) nie powinna mieć nic wspólnego ze źródłem ich pochodzenia, więc m. in. dlatego powinno się wydzielić tą warstwę. Jeśli chodzi o mapper, jest on coś w rodzaju "adaptera" klasy Table, który może dostarczać swój (inny lub taki sam) interfejs oraz zwraca nie obiekty Rowset, czy Row, ale tablicę obiektów lub jeden obiekt modelu heremtyzujących dane.

To o czym piszę to wzorzec Data Access Object, jego implementacją jest przykładowo Propel - klasy z przyrostkiem Peer pobierają dane z bazy danych i tworzą obiekty klasy bez przyrostka "Peer" (reprezentację danych).

Kilka dni temu zadałem podobne pytanie: Temat: ZendFramework_model_jak_to_dobrze_zorganizowac

Teraz znalazłem takie coś: http://weierophinney.net/matthew/archives/...astructure.html i zaczynam się w to wgryzać.

Z tego ci czytałem przez ostatnbie kilka dni to najlepiej jest mieć 3 klasy:
1 obiekt przechowujący dane
2 klasa rozszerzająca zend_db_table_abstract
3 klasa która to połączy - korzystając z obiektu klasy 2 upchnie dane do obiektu klasy 1 i go zwróci - obiekt z tej klasy robimy sobie w kontrolerze i jemu przekazujemy i odbieramy dane

jakoś tak to widzę.

Wszędzie jest dużo teori, ale jakieś przykłady praktyczne ciężko znaleźć.

Narazie boje sie nawet myśleć na temat relacji między tabelami...

Może ktoś powiedzieć czy dobrze kombinuję? a najlepiej podać jakieś przykładowe aplikacje na zf >=1.8

edit:
tutaj też znalazłem dość sensowny tekst na temat: http://akrabat.com/2008/12/13/on-models-in...rk-application/
Zaczyna mi się coraz bardziej rozjaśniać.
I widzę że ten przykład w tutorialu (QuickStart) na stronie ZF jest jakiś "dziwny", w sumie struktura plików jest podobnie jak opisałem wyżej, ale bezpośrednio w kontrolerze jest tam tworzony obiekt z klasy będącej "pojemnikiem" na dane. Przez co w tej klasie muszą być zdublowane metody klasy 3 z moich podpunktów.

Czy ktoś zaznajomiony z tematem mógłby się jakoś odnieść do mojej wypowiedzi i tamtego tutoriala?