Propel od środka

Stosując bibliotekę Propel unikniemy tych żmudnych działań i uniezależnimy naszą aplikację od konkretnej bazy danych. Spójrzmy na Listing 2. Przedstawiony na nim kod wykonuje te same operacje, co skrypt z Listingu 1. Nie znajdziemy w nim jednak ani jednego bezpośredniego odwołania do DB. Nie otwieramy połączeń ani nie piszemy zapytań SQL. Wykonujemy natomiast proste operacje na obiektach. Nasz program jest odseparowany od relacyjnej bazy danych przez dodatkową warstwę abstrakcji, której zadaniem jest transformacja operacji na obiektach na odpowiednie zapytania do DB i vice versa. Taką warstwę określamy mianem mapowania relacyjno-obiektowego, czyli ORM (ang. Object Relational Mapping). Więcej szczegółów na temat ORM zamieściliśmy w Ramce ORM i Propel.

Ze względu na swoją rolę, warstwa ORM musi posiadać informacje o strukturze bazy danych, modelu obiektowym aplikacji i wzajemnych powiązaniach tych dwóch światów. Propel używa w tym celu pliku XML. Pamiętajmy jednak, że PHP nie przechowuje żadnych danych pomiędzy wywołaniami skryptu. Musielibyśmy więc parsować ten plik za każdym wywołaniem aplikacji, co znacznie spowolniłoby jej działanie. Dlatego też Propel generuje klasy PHP na podstawie definicji z pliku XML. Klasy te są następnie wykorzystywane w trakcie uruchamiania programu, a XML nie jest potrzebny, o ile nie wprowadzamy zmian w strukturze bazy danych. Tak naprawdę więc mamy do czynienia z dwoma modułami biblioteki: pierwszy z nich, o nazwie Propel-generator przekształca pliki XML do klas PHP, a drugi, Propel-runtime pozwala uruchamiać wygenerowane klasy. Na Rysunku 3 widzimy schematyczne przedstawienie sposobu, w jaki działa Propel.

Propel w działaniu

Najwyższy czas, by wykorzystać zdobytą wiedzę w praktyce. W kilku kolejnych krokach utworzymy w pełni działającą aplikację korzystającą z dobrodziejstw Propela. Spójrzmy najpierw na Listing 3. Zaprezentowany na nim plik jest XML-owym opisem struktury omówionej wcześniej bazy danych (Rysunek 1).

Kolejnym zadaniem będzie wykorzystanie przygotowanego pliku XML do wygenerowania klas, które będziemy wykorzystywać w naszej aplikacji. Sam proces generacji wykonywany jest przy pomocy narzędzia o nazwie Phing, które jest systemem automatyzującym budowanie projektu, w filozofii działania podobnym do make i wzorowanym na ant z Javy. Po prawidłowym skonfigurowaniu całego środowiska pracy (więcej informacji znajduje się w Ramce Instalacja), wystarczy wydać komendę: phing -Dproject=[nazwa projektu] z katalogu, w którym znajduje się plik build.xml. W efekcie zostaną wygenerowane pliki i katalogi, których strukturę pokazujemy na Rysunku 4. Zawartość podkatalogów o nazwach map i om zostanie nadpisana w przypadku powtórnego generowania klas (np. po zmianach w strukturze DB), więc nie należy dokonywać w nich własnych modyfikacji. Foldery te pełnią następujące funkcje:

• map (od ang. mapping) przechowuje klasy zawierające opis struktury DB, modelu obiektowego i ich wzajemnych powiązań. Stanowią one reprezentację informacji zawartych w pliku XML, ale w postaci klas PHP. Dzięki takiemu podejściu, wszystkie metainformacje potrzebne w trakcie działania aplikacji są natychmiast dostępne bez konieczności parsowania pliku XML. Dla każdej z tabel opisanej w pliku XML zostanie wygenerowana jedna klasa o nazwie [NazwaTabeli]MapBuilder.php. O ile nanoszenie własnoręcznych zmian w tych plikach nie jest wskazane, to bez przeszkód możemy używać wygenerowanych klas, aby uzyskać informacje o strukturze tabeli, np. listę kolumn,
• om (od ang. object mapping) to folder zawierający klasy odpowiedzialne za użycie obiektów w aplikacji, a dokładniej za ich mapowanie do instrukcji SQL. Dla każdej tabeli, która pojawia się w XML-u otrzymamy dwie automatycznie wygenerowane klasy: Base[NazwaTabeli].php i Base[NazwaTabeli]Peer.php. Pierwsza z nich odpowiada pojedynczym rekordom w tabeli. Z kolei Base[NazwaTabeli]Peer reprezentuje dane i operacje związane z całą tabelą.

Po omówieniu zawartości folderu om łatwo będzie zrozumieć, co trafia do głównego katalogu. Pliki o nazwach [NazwaTabeli]Peer.php i [NazwaTabeli].php zawierają definicje klas, które rozszerzają klasy z podkatalogu om. Pliki znajdujące się w głównym katalogu zostały przygotowane do rozbudowy - tutaj możemy wprowadzać własne zmiany i rozszerzenia, a efekt naszych prac nie zostanie nadpisany w przypadku powtórnego generowania projektu. Na Rysunku 5 widzimy diagram UML dla wszystkich wspomnianych przed chwilą klas.

Jesteśmy już bardzo blisko uruchomienia przykładu podobnego do przedstawionego na Listingu 2. Pozostało jedynie założenie tabel tworzących strukturę bazy danych i skonfigurowanie parametrów połączenia do niej. W pierwszym zadaniu również pomoże nam Propel: raz już przecież opisaliśmy strukturę DB, tworząc plik XML. Propel potrafi skorzystać z tych informacji. Wystarczy podać parametry docelowej bazy danych (jej typ i dane potrzebne do nawiązania połączenia) oraz wywołać komendę:

phing -Dproject=[nazwa projektu] -Dtarget=insert-sql.

Rysunek 1. Schemat przykładowej bazy danych

Rysunek 2. Przykładowy formularz do wprowadzania nowej pozycji do oferty