w Zend, Dlaczego używamy klasy modelu DB i klasy Mapper jako dwóch oddzielnych?

Question

Pracuję nad projektem Zend, mam na myśli inny projekt Zend, aby stworzyć nowy projekt Zend. Ale nie lubię ślepo podążać za tym projektem bez zrozumienia. W strukturze katalogów Zend w klasie Model są głównie dwa typy klas, które widzę, podobnie jak w

- models 
    - DbTables 
     - Blog.php //Extends Zend_Db_Table_Abstract 
    - Blog.php  // Contains methods like validate() and save() 
    - BlogMapper.php // Also Contains methods like validate(Blog b) & save(Blog b) 

Dlaczego ta konkretna struktura jest przestrzegana? Czy należy oddzielić klasę obiektu i klasę modelu bazy danych?

Proszę wyjaśnić.

Answer 1

DataMapper is a design pattern from Patterns of Enterprise Application Architecture.

Mapowanie danych to warstwa oprogramowania, która oddziela obiekty znajdujące się w pamięci od bazy danych. Jego obowiązkiem jest przekazywanie danych między nimi, a także izolowanie ich od siebie. Z Data Mapper obiekty w pamięci nie muszą nawet wiedzieć, że istnieje baza danych; nie potrzebują kodu interfejsu SQL, a na pewno nie znają schematu bazy danych.

Sposób przechowywania danych w relacyjnej bazie danych zwykle różni się od struktury obiektów w pamięci. Na przykład obiekt będzie miał tablicę z innymi obiektami, podczas gdy w bazie danych twoja tabela będzie miała klucz obcy zamiast innej. Z powodu wartości object-relational impedance mismatch używana jest warstwa pośrednicząca między obiektem domeny a bazą danych. W ten sposób możesz ewoluować zarówno bez wpływu na inne.

Oddzielenie odpowiedzialności za odwzorowanie w jej własnej warstwie jest również bardziej zgodne z Single Responsibility Principle. Twoje obiekty nie muszą wiedzieć o logice DB i odwrotnie. Daje to większą elastyczność podczas pisania kodu.

Jeśli nie chcesz używać modelu domeny, zazwyczaj nie potrzebujesz programu DataMapper. Jeśli twoje tabele bazy danych są proste, możesz być lepiej z TableModule i TableDataGateway lub nawet po prostu ActiveRecord.

Z różnych innych wzorów zobaczyć moją odpowiedź na

• ORM/DAO/DataMapper/ActiveRecord/TableGateway differences? i
• http://martinfowler.com/eaaCatalog/index.html

Answer 2

Idea modelu jest zawinąć logiczny zbiór danych wewnątrz kodu.

Ideą DataMapper jest powiązanie tego zbioru danych na poziomie aplikacji z tym, jak je przechowujesz.

Dla wielu implementacji ActiveRecord, struktura nie zapewnia tego oddzielenia intencji i może to prowadzić do problemów.Na przykład, model blogpost może owinąć się podstawowe informacje o blogu jak

• tytułem
• autor
• ciało
• date_posted

Ale może też chce go mieć zawierają coś takiego:

• number_of_reads
• number_of_likes

Teraz można przechowywać wszystkie te dane w jednej tabeli MySQL na początku, ale jak swoim blogu rośnie i staje się bardzo sławny, to okaże się, że dane statystyczne ze sobą bardzo dużo trafień i chcesz przenieść go na oddzielny serwer bazy danych.

Jak zmieniłbyś sposób migracji tych pól obiektów BlogPost do innego magazynu danych bez zmiany kodu aplikacji?

Za pomocą DataMappera można modyfikować sposób zapisywania obiektu w bazie (i) oraz sposób jej ładowania z bazy danych. Pozwala to na dostrojenie mechanizmu pamięci masowej bez konieczności zmiany faktycznego gromadzenia informacji, na których opiera się aplikacja.