[ZF][ZendFramework] Bodowa Modelu Opcje

[markus12]

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!

[quality]

Poczytaj:

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

pozdrawiam

[markus12]

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 

[quality]

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

Ten post edytował quality 18.02.2011, 15:32:57

[Lysiur]

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??

Ten post edytował Lysiur 14.12.2012, 10:54:40

[irmidjusz]

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ń).

[Lysiur]

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.

[CuteOne]

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 

(IMG:style_emoticons/default/wink.gif)

Ten post edytował CuteOne 20.12.2012, 12:39:37

[ze4lot]

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.