Witam,

większość z was na pewno zna poradnik Quickstart w dokumentacji ZendFrameworka. Jest tam przykład budowy prostej książki gości.

I teraz chciałem zrobić katalog książek w ZF. Mam w bazie tabelki: Book, Author, Book_Author, Book_Genre, itd. Bazując na przykładzie modelu z dokumentacji Quickstart mogę zrobić coś w tym stylu:

[PHP] pobierz, plaintext 
class Application_Model_Book
{
    protected $_title;
    protected $_id;
 
    public function __construct(array $options = null)
    {
        if (is_array($options)) {
            $this->setOptions($options);
        }
    }
 
    public function __set($name, $value)
    {
        $method = 'set' . $name;
        if (('mapper' == $name) || !method_exists($this, $method)) {
            throw new Exception('Invalid book property');
        }
        $this->$method($value);
    }
 
    public function __get($name)
    {
        $method = 'get' . $name;
        if (('mapper' == $name) || !method_exists($this, $method)) {
            throw new Exception('Invalid book property');
        }
        return $this->$method();
    }
 
    public function setOptions(array $options)
    {
        $methods = get_class_methods($this);
        foreach ($options as $key => $value) {
            $method = 'set' . ucfirst($key);
            if (in_array($method, $methods)) {
                $this->$method($value);
            }
        }
        return $this;
    }
 
    public function setTitle($text)
    {
        $this->_title = (string) $text;
        return $this;
    }
 
    public function getTitle()
    {
        return $this->_title;
    }
 
    public function setId($id)
    {
        $this->_id = (int) $id;
        return $this;
    }
 
    public function getId()
    {
        return $this->_id;
    }
}
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
class Application_Model_BookMapper
{
    protected $_dbTable;
 
    public function setDbTable($dbTable)
    {
        if (is_string($dbTable)) {
            $dbTable = new $dbTable();
        }
        if (!$dbTable instanceof Zend_Db_Table_Abstract) {
            throw new Exception('Invalid table data gateway provided');
        }
        $this->_dbTable = $dbTable;
        return $this;
    }
 
    public function getDbTable()
    {
        if (null === $this->_dbTable) {
            $this->setDbTable('Application_Model_DbTable_Book');
        }
        return $this->_dbTable;
    }
 
    public function save(Application_Model_Book $book)
    {
        $data = array(
            'title' => $book->getTitle(),
        );
 
        if (null === ($id = $book->getId())) {
            unset($data['id']);
            $this->getDbTable()->insert($data);
        } else {
            $this->getDbTable()->update($data, array('id = ?' => $id));
        }
    }
 
    public function find($id, Application_Model_Book $book)
    {
        $result = $this->getDbTable()->find($id);
        if (0 == count($result)) {
            return;
        }
        $row = $result->current();
        $book->setId($row->id)
                  ->setTitle($row->title);
    }
 
    public function fetchAll()
    {
        $resultSet = $this->getDbTable()->fetchAll();
        $entries   = array();
        foreach ($resultSet as $row) {
            $entry = new Application_Model_Book();
            $entry->setId($row->id)
                  ->setTitle($row->title);
            $entries[] = $entry;
        }
        return $entries;
    }
 
}
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
class BookController extends Zend_Controller_Action
{
 
    public function init()
    {
        /* Initialize action controller here */
    }
 
    public function indexAction()
    {
        $book = new Application_Model_BookMapper();
        $this->view->entries = $book->fetchAll();
    }
 
}
[PHP] pobierz, plaintext 

To jest w 90% kod z dokumentacji ZF. Ciekawe podejście, jedna klasa do obiektu książki ze zmiennymi takimi jak kolumny w bazie, druga klasa do operacji z bazą, której przesyłamy obiekt tej pierwszej klasy.

To wszystko rozumiem i jest ok. Ale teraz dochodzę do tego, że chciałbym pobrać listę książek wraz z nazwiskami ich autorów, gatunkami do których są przypisane i wyświetlić taką listę np. 20 książek wraz z pełnymi informacjami o każdej. W tej chwili metoda FetchAll wyciąga mi wszystko z tabelki Book. Nie mam pojęcia w jaki sposób podejść do tego, żeby dołączyć do tego też dane z innych tabel.

Tabela Author_Book jest do relacji między książkami i autorami. (czyli książka ma kilku autorów).

Nie wiem jak to ładnie zrobić żeby było zgodne z MVC itd. Czy porzucić całkowicie tej sposób z dwoma klasami czy nie, po prostu proszę o wskazówki w jaki sposób się takie coś robi.

pozdrawiam!

Poczytaj:

http://framework.zend.com/manual/en/zend.db.select.html

pozdrawiam

chodziło mi bardziej o to, czy pobierać z bazy dane o autorach powinienem w metodzie FetchAll klasy Application_Model_BookMapper i czy nazwiska autorów mają trafić do obiektu klasy Application_Model_Book. Czy może metoda FetchAll klasy Application_Model_BookMapper powinna poprosić metodę klasy Application_Model_AuthorMapper o autorów. Czy może powinienem pobrać same dane z tabelki Book i kontroler powinien na ich podstawie poprosić o autorów klasę modelu związanego z tabelką Autorów.

Jeśli zrobię wszystko w metodzie FetchAll klasy Application_Model_BookMapper to jakoś tak??:

[PHP] pobierz, plaintext 
    public function fetchAll()
    {
        $resultSet = $this->getDbTable()->fetchAll();
        $entries   = array();
        foreach ($resultSet as $row) {
            $entry = new Application_Model_Book();
            $entry->setId($row->id)
                  ->setTitle($row->title);
// pobranie autorów, gatunków i wrzucenie ich do $entry??
            $entries[] = $entry;
        }
        return $entries;
    }
[PHP] pobierz, plaintext 

Metoda fetchAll() - to jest standardowa metoda Zend_Db_Abstract - pobiera ona wszystkie rekorny z konkretnej tabeli.
Nadpisywanie jej nie sadze ze jest dobrym pomyslem.

Raczej proponuje ci stworzyc nowa metode publiczna fetchAllBook() i w niej napisac sobie zapytanie na podstawie Zend_Db_Select i tak pobrac dane.

I mowie poczytaj o Zend_Db_Select - bo tak Ci nie wyjdzie za bardzo laczenie tabel
Przyklad :

[PHP] pobierz, plaintext 
 
class Administration_Model_Wydawnictwa extends Zend_Db_Table {
 
    protected $_name = 'wydawnictwa';
    protected $_primary = 'id';
 
    /**
     * Get all  in list
     */
    public function getWydawnictwa($id)
    {
        $select = $this->select()
                        ->from(array('this'=>$this->_name),array('id','rodzaj_id','sort','publikacja','cena','nazwa','uwaga'))
                        ->setIntegrityCheck(false);
 
        $select ->join('base_categories AS d', 'd.id = this.dzial_id','name AS dzial')
                ->joinLeft('base_categories AS s', 's.id = this.stanowisko_id','name AS stanowisko')
                ->join('wydawnictwo_redaktorzy AS c', 'c.id = this.redaktor_id', 'c.id AS redaktor_id, CONCAT_WS(" ",c.imie, c.nazwisko) AS name')
                ->where("this.wydawnictwo_id=".$id)
                ->order('d.id ASC', 'this.sort ASC');
 
        $rows = $this->_db->fetchAll($select);
 
        return $rows;
    }
 
}
[PHP] pobierz, plaintext 

Pozdrawiam

Witam, chciałbym odświerzyć nieco temat, ponieważ męczy mnie to samo zagadnienie co @markus12. Chodzi mi dokładnie jak najlepiej rozwiązać problem, gdy potrzebujemy pobrać "przysłowiową" książkę, oraz jej autorów, gatunek, etc. Oczywiście możemy zrobić funckję fetchAllBook(), ale zastanawia mnie jej zawrtość.

Użytkownik @quality, podał rozwiązanie bazujące na Zend_Db_Select wszsytko jest okej, ale wynik zwracany jest w postaci tablicy, kórej część pól nie ma odwzorowania w modelu Book. Zakładając, że przyjmujemy, iż mapper zwraca nam obiekt, to jakie atrybuty powinna posiadać klasa Book?

[PHP] pobierz, plaintext 
class Application_Model_Book {
 
protected $_id = null;
protected $_title = null;
 
protected $_autors = array();
 
public function setAutor(Application_Model_Autor $oAutor) {
$this->_autors[] = $oAutor;
return $this;
}
//....
}
 
//Mapper
public function fetchAllBook()
    {
        $resultSet = $this->getDbTable()->fetchAllBook(); // Czy zamiast tego lepiej poprstu zrobić Zend_Db_Select i zbudować zapytanie, a nie używać ZEnd_Db_Table w Application_Model_DbTable_Autor
        $entries   = array();
        foreach ($resultSet as $row) {
            $entry = new Application_Model_Book($row); //Konstruktor uzupełni atrybuty
            $entry->setAutor(new Application_Model_Autor($row)); //j/w (o ile nie zostaną nadpisane),
            $entries[] = $entry;
        }
        return $entries;
    }
 
[PHP] pobierz, plaintext 

Męczy mnie to zagadnienie, i nie bardzo mogę znaleźć rozwiązanie które by mnie satysfakcjonowało. Bo teraz szybko się okaże, że trzeba będzie wyświetlić obok listy książki i autorów, np.: gatunek, dział w którym się znajduje oraz np.: budynek. Model będzie się rozrastał i rozrastał. Rozbudujemy obiekt wg. sposobu opisanego wyżej.

Idąc dalej krokiem, będzie potrzeba w którymś miejscu wyświetlić jescze adres budynku w którym ta książka się znajduje, i mamy (np.: w widoku):

[PHP] pobierz, plaintext 
//@var $oBook Application_Model_Book
foreach(.... $key => $oBook):
.... $oBook->getDepartament()->getAddress()->getFullAddres();
endforach;
[PHP] pobierz, plaintext 

W takiej sytuacji robi się pewne misz-masz, bo na jednej liście (widoku) będziemy potrzebować wszystkich danych (łącznie z działem i budynkiem), a w innym widoku (bez tych dodatkowych danych). Wywołując fetchAllBook (w maperze) pakujemy obiekt złożony mimo, że nie zawsze jest on potrzebny.

Można zrobić tak, że w modelu Book, zrobić tak, że:

[PHP] pobierz, plaintext 
class Application_Model_Book {
...
public function getDepartament() {
      $mDepartament = new DeparatamentMapper();
      $this->departament = $mDepartament->findByIdBook($this->_id);
}
...
}
[PHP] pobierz, plaintext 

Jednakże w takiej sytuacji przy foreachowaniu $oBook będziemy za każdym razem wysyłali dodatkowe sqlki.


Jak rozwiązujecie takie sytuacje??

Ja robię różnie w zależności od potrzeb. Chodzi głównie o wydajność pobierania danych z bazy. Im więcej zapytań, tym gorzej, więc lepiej robić jedno zapytanie pobierające dane do tabeli głównej z 3 joinami, niż 4 oddzielne zapytania. Ale... różnie to bywa, bo po pierwsze, zależy ile jest na raz wierszy pobieranych, ile joinowanych tabel i ile kolumn mają te tabele, bo budowanie i wypełnianie tych wszystkich obiektów-modeli zabiera czas i zużywa pamięć, i może to być naprawdę duży problem. Dlatego trzeba to wyważyć. Można też pisać sobie specjalne metody do pobierania różnych zestawów danych w zależności od zapotrzebowania - np. na jednym widoku potrzebujesz wyświetlić tylko 2 kolumny z tabeli A, a na innym 3 kolumny z tabeli A i jeszcze 8 kolumn z joinowanych tabel B, C i D - więc dwie różne metody będą w sam raz.
Poza tym, do pobierania danych tylko-do-odczytu (tylko do prezentacji) nie trzeba ich pobierać jako obiektów ORM, a wystarczą przecież proste zapytania SQL i wyniki tablicowe - potrafi to być znacznie wydajniejsze, niż pobranie tych samych danych za pomocą modeli. Modele są dobre głównie do logiki biznesowej i zapisu danych - bardzo wygodne, w zasadzie trudno je przecenić. Ale wyświetlanie (zwykle jest o kilka rzędów wielkości więcej operacji odczytu, niż zapisu) nie potrzebuje modeli - dedykowane, zoptymalizowane zapytania SQLowe o konkretne dane, zwracane jako tablice, potrafią być zdecydowanie wydajniejsze (wszystko zależy od obciążenia strony i ilości pobieranych danych oraz skomplikowania zapytań).

Dziękuje @irmidjusz za odpowiedź, myślałem ostatnio nad tym co napisałeś, a przede wszystkim jak najoptymalnie zwracać wyniki (np.: złączonych kilku tabel) z Mappera. Domyślnie mapper powinien zwracać nam obiekt, ponieważ faktycznie często będzie tak, że zawartość złączonych tabelach będzie miała w jednym widoku 3 kolumny A, 2 B lub w innej konfiguracji. Niestety często jest tak, że w takich sytuacjach przydało by mi się na wejściu dostać obiekt, który byłby w stanie z wybranych atrybutów danego obiektu, np.: person zwrócić tablicę zawierającą id,firstName,surname, gdyż np.: z takiej tablicy poprzez helpera tworzę link do profilu czy ajaxowe okienko. Dlatego wygoniej będzie i jendolicie będzie wywołać w widoku

[PHP] pobierz, plaintext 
$this->Profile_Link($oPerson->getPersonLink('worker'));
//niż konstrukcja
$this->Profile_Link(array('id'=>'123213','firstName'=>'P','surname'=>'Test'));
[PHP] pobierz, plaintext 

Pomyślałem, że zrobię clasę, np.: PersonList, który miałby wszystkie wymagane pola (zwracane, przez którekolwiek zapytanie łączące tabele). Zwracany wynik przez fetchAll() - czyli tablica, mapper wstawiałby mi to w klasę typu (kolekcji) PersonsCollection (implementująca Iterator,Countable), i przypadku chęci pobrania danego wiersza (złączonego z kilku tabel), zwracałby właśnie new PersonList();

Aczkoliwek, to narazie koncepcja, wyjdzie w praniu czy takie rozwiązanie ma sens, i czy nie jest zbyt zasoborzerne. Napewno będzie "cięższe" niż przekazanie samej tablicy zwracane przez mapper'a, ale rozwiązanie może ujednolicić kod.

Weź pod uwagę fakt, że zapytanie, które łączy kilka tabel, może zwrócić coś takiego:

[PHP] pobierz, plaintext 
$rows = array(
     array('id'=>1, 'title'=>'xxx', 'autor' => 'Heniu'),
     array('id'=>1, 'title'=>'xxx', 'autor' => 'Wojtek'),
     array('id'=>1, 'title'=>'xxx', 'autor' => 'Pędzisław')
);
[PHP] pobierz, plaintext 

a co gorsza to samo zapytanie, może zwrócić

[PHP] pobierz, plaintext 
$rows = array(
     array('id'=>1, 'title'=>'xxx', 'autor' => 'Heniu'),
     array('id'=>2, 'title'=>'yyy', 'autor' => 'Heniu'),
     array('id'=>2, 'title'=>'yyy', 'autor' => 'Wojtek')
);
[PHP] pobierz, plaintext 

lub

[PHP] pobierz, plaintext 
$rows = array(
     array('id'=>1, 'title'=>'xxx', 'autor' => 'Heniu')
);
[PHP] pobierz, plaintext 

edit: do dzisiaj nie znalazłem odpowiedniej metody przekształcania tego typu danych w obiekt bez użycia:

[PHP] pobierz, plaintext 
$array = array();
foreach($rows as $row) {
 
     if(!isset($array[$row->id])) {
            $array[$row->id] = $row;
            $array[$row->id]['autor'][] = $row->autor;
     }
     else {
            $array[$row->id]['autor'][] = $row->autor;
     }
}
[PHP] pobierz, plaintext 

Spotkałem się kiedyś z modelami pomocniczymi agregującymi inne modele dziedziczące bo Zend_Db_Table. Zrobione to było na zasadzie Dependency Injection. Modele pomocnicze nie miały swoich tabel w bazie, a jedynie obsługiwały i łączyły standardowe modele.