ORM - czy warto

Obejrzenie kilku przykładów zastosowania Propela daje nam wyobrażenie o skali wysiłku i czasu, jakie możemy dzięki niemu zaoszczędzić w trakcie pisania aplikacji WWW korzystającej z bazy danych. Dodatkowo, niezależność aplikacji od konkretnego systemu bazy danych daje nam nie tylko możliwość uruchamiania oprogramowania np. na MySQL-u, PostgreSQL-u i Oracle, ale również zabezpiecza nas w pewnym stopniu przed przykrymi skutkami zmian nazw tabel i ich pól. Niestety, pozbawimy się tej zalety, jeśli w naszych skryptach umieścimy instrukcje SQL charakterystyczne dla dialektu określonego systemu baz danych.

Mimo niewątpliwych zalet, jakie niesie ze sobą użycie rozwiązania typu ORM, warto zastanowić się nad potencjalnymi pułapkami. Przede wszystkim musimy pamiętać, że używanie narzędzia mapującego wiąże się z napisaniem i pielęgnowaniem metainformacji. W przypadku Propela przybierają one postać pliku XML. Z drugiej strony, przy standardowym podejściu, wszystkie metainformacje są rozrzucone po całej aplikacji w instrukcjach SQL. Istnieje szansa, że mimo większego początkowo nakładu pracy, podejście oparte o ORM okaże się łatwiejsze w utrzymaniu i rozwoju. Wynika z tego prosty wniosek, że Propel i podobne biblioteki przydają się w dużych projektach, natomiast w przypadku małych i krótko żyjących mogą stanowić tylko niepotrzebną komplikację.

Innym, często podnoszonym przeciwko rozwiązaniom typu ORM argumentem są kwestie wydajnościowe. W przypadku części konkretnych zapytań SQL może okazać się, że kod wygenerowany automatycznie przez warstwę pośrednią będzie mniej efektywny niż napisany ręcznie przez programistę. Trudno tutaj o jednoznaczne recepty, bo wydajność konkretnego programu zależy w dużej mierze od fizycznego modelu danych. Jako ogólną zasadę można przyjąć, iż narzędzia ORM najlepiej sprawdzą się w przypadku stron, na których występuje dużo zapytań o pojedyncze obiekty z różnych tabel. Dobrym przykładem może być sklep internetowy, gdzie oprócz karty produktu widzimy jego oceny i recenzje, nazwę zalogowanego użytkownika i zawartość koszyka, aktualnych solenizantów, kategorie sklepowe i kilka nowości. Z dużą ostrożnością należy z kolei stosować ORM w aplikacjach, gdzie nie manipulujemy obiektami, a danymi tabelarycznymi, np. raporty, zestawienia itd. Tam standardowe podejście jest bardziej naturalne i efektywniejsze.

Niezależnie od typu aplikacji, konkretne informacje o jej wydajności możemy zdobyć dopiero po sesji profilowania. Nasza intuicja często zawodzi i wąskie gardła znajdują się w zupełnie innych miejscach, niż się tego spodziewamy. Nawet jeśli w programie kilka operacji musi wykonywać się bardzo szybko, to najlepiej zakodować w SQL-u tylko te szczególne przypadki, np. nadpisując przy dziedziczeniu wygenerowany kod, standardowo zaś posługiwać się ORM.

Rysunek 4. Pliki i katalogi utworzone przez Propel-generator