2009-06-30 12 views
9

W modelu Zend Framework Quickstart nastąpiła zmiana w modelach rozszerzających Zend_Db_Table_Abstract na wzorzec bramy danych tabel.Zend Framework ORM-tablica danych tabeli vs. rozszerzenie Zend_Db_Table_Abstract

Osobiście nie miałem zbyt dużego doświadczenia z tym wzorcem i nadal słyszę, że najprawdopodobniej będzie on stosowany zamiast starego sposobu.

Krótki przykład z QuickStart:

stary sposób:

class Default_Model_Guestbook extends Zend_Db_Table_Abstract 
{ 
    protected $_name = 'tablename'; 

    // do stuff 
} 

nowy sposób:

// The actual model 
class Default_Model_Guestbook 
{ 
    protected $_comment; 
    protected $_created; 
    protected $_poster; 
    // list continues with all columns 
} 

// Dbtable for this model 
class Default_Model_DbTable_Guestbook extends Zend_Db_Table_Abstract 
{ 
    /** Table name */ 
    protected $_name = 'guestbook'; 
} 

// Mapper 
class Default_Model_GuestbookMapper 
{ 
    public function save($model); 
    public function find($id, $model); 
    public function fetchAll(); 
} 

Z mojego brakuje doświadczenia z tego stylu programowania , Trudno mi zrozumieć actua Korzystam z tego ostatniego sposobu; Rozumiem, że ta metoda w jak największym stopniu oddziela bazę danych od rzeczywistej logiki, co teoretycznie powinno ułatwić przejście na inną platformę bazodanową. Jednak naprawdę nie widzę, aby tak się działo w każdym projekcie, nad którym pracuję.

Nie ma prawie żadnych wątpliwości, że coś przeoczam, dlatego chciałbym usłyszeć twoją radę.

Pytanie:

  • Czy ktoś mógłby mi wyjaśnić, dlaczego (lub jeśli) ten ostatni jest lepszy praktyka?

  • powinienem przełączyć ze starej drodze do nowej drogi lub są nadal uzasadnione powody do przyklejania z modeli, które reprezentują tabele bazy danych?

Z góry dziękuję.

+0

Naprawdę nie jest to odpowiedź, więc to ona. Po kilku latach dowiedziałem się, że abstrakcja jest formą sztuki, sztuka nie zawsze ma powody. Dziś streszczam minimum potrzebne i robię rzeczy, więc będę musiał kodować tak mniej, jak to możliwe, co w twoim przypadku, jeśli dodasz ten dodatkowy poziom abstrakcji, nie nastąpi. –

+0

Aby wyjaśnić, Zend_Db_Table * jest * implementacją wzorca TDG/RDG. To, co się dzieje, to to, że przechodzą do patteru Mapowania Danych. – jason

Odpowiedz

6

Oto moje wyjaśnienie, dlaczego jest to lepsze praktyki:

myślę prawdziwy zaletą tego jest możliwość bezproblemowo zmienić swoje źródła danych. Dodając do aplikacji dodatkową warstwę abstrakcji, modele nie są już tabelą bazy danych (nigdy nie powinny, moim zdaniem), ponieważ model powinien być reprezentacją danych (a nie bramą do niego). Warstwa dostępu do bazy danych powinna być hermetyzowana przez model, co zapewnia większą elastyczność.

Załóżmy na przykład, że aplikacja musi rozpocząć korzystanie z usługi SOAP lub XML-RPC, ponieważ jest to źródło danych/pamięć masowa. Korzystając z metody odwzorowania danych, masz wyraźną przewagę, ponieważ masz już niezbędną strukturę do dodania tych konkretnych interfejsów warstwy danych bez dużej (jeśli w ogóle) ingerencji w istniejące modele.

Czy jednak to zrobić? To jest pragmatyczne pytanie. Osobiście lubię mieć spokój ducha, że ​​rozwijam coś elastycznego i przestrzegam (uzgodnionych) najlepszych praktyk. Jednak tylko Ty wiesz, czy stworzenie bardziej elastycznej aplikacji ułatwi Twojemu projektowi, teraz lub w przyszłości, zbudowanie i utrzymanie.

Dla mnie po prostu podoba mi się uczucie, że coś buduję, uważam za najlepszą praktykę i często płaci się dywidendę.

+0

Chociaż potwierdzasz to, o czym już myślałem, jest to świetna odpowiedź na obie części mojego pytania i zdecydowanie pomaga mi podjąć lepszą decyzję. Dzięki! –

+0

Cieszę się, że mogę pomóc. Ponadto, jeśli chcesz zrobić dalsze czytanie, Matthew Weier O'Phinney ma kilka przydatnych slajdów z jego prezentacji na holenderskiej konferencji PHP. http://www.slideshare.net/weierophinney/zend-framework-workshop-dpc09 (tam gdzie rozpoczyna się dyskusja modelowa, znajduje się slajd 28). –

+0

Ciekawe, nie mogę zrozumieć koncepcji tego również: P to trochę jak nad inżynierią. Czym różni się mapper zamiast zmieniania modelu, jeśli zmieni się źródło danych? A w praktyce, ile razy to się naprawdę dzieje, to jest mnóstwo dodatkowych linii do napisania czegoś, co po prostu dodaje mi więcej uczucia: p Ale co ja wiem? – Chris

0

Jest to przydatne, ponieważ można wykonać $insert = new Model_Guestbook($param1, $param2, $param3); - oznacza to, że gdy ktoś przychodzi do projektu, może on łatwo utworzyć nową instancję bez znajomości struktury bazy danych (poprzez sprawdzenie interfejsu źródło/przez model). Jest to tylko jedna z zalet tej metody oferuje :)

+0

Nie uważam tego za dużą korzyść, ponieważ oznaczałoby to zmianę schematu, co spowodowałoby konieczność zmiany odpowiedniego kodu w więcej niż jednym miejscu. Wciąż czuję, że drastycznie coś przeoczam. –