Główna zaleta PersistentObject z ezComponents to czas. Obsługa nowej tabelki powstaje poprzez zdefiniowanie zestawu reguł, podczas gdy całą mechanikę odwala już odpowiednia klasa. W moich projektach wszystkie obiekty DAO w całości piszę ręcznie, od początku do końca. Wiele z tabel nie jest połączonych z innymi jakimiś skomplikowanymi zależnościami i tam taka unifikacja bardzo by się przydała, zwłaszcza że już kilka razy zdarzyło mi się, że dodałem nowe pole, dopisałem je do metody insert(), a do update() już nie :). Nowe wersje eZ-a posiadają dodatkowo obsługę relacji.

Co mnie wkurza w takim podejściu, to wszelkiej maści kreatory zapytań. W teorii mogą mieć one sens przy przenośności projektu między bazami danych, ale różnice bywają tak duże, że siłą rzeczy trzeba całe fragmenty kodu pisać całkowicie od nowa, by wykorzystać oferowane możliwości. Reszta sytuacji - czym się niby ma różnić taki kod:

$query = new selectQuery;
$query -> addField('id');
$query -> addField('title');
$query -> addTable('table1', 't1');
$query -> setLessThanStatement('price', 6.70);
$query -> setLimit(56);

od takiego kodu:

$stmt = $pdo -> prepare('SELECT `id`, `title` FROM `table1` WHERE `price` < :price LIMIT 56');
$stmt -> bindValue(':price', 6.70, PDO::PARAM_FLOAT);

Czysta sztuka dla sztuki - na mój gust po to pisze się takie warstwy abstrakcji, by odseparować jedno od drugiego. Akurat w tym wypadku moje ręczne tworzenie ma jedną przewagę: gdybym zechciał np. nazwy wszystkich pól i tabel mieć po rumuńsku, poprawkom uległaby tylko grupa plików - kod akcji oraz formularze pozostałyby bez zmian. A takie rzeczy się zdarzają. Jest nowy projekt, szkoda wyrzucać połowy kodu, bo się przyda, tylko tytuły trzeba pozmieniać. Taki autorski system nadaje się też w sytuacjach, gdy system ma pracować na mocno niestandardowych danych (np. drzewka - czysty kod wygląda koszmarnie, ale na jakimś frameworku bez dedykowanej biblioteki do drzew pewnie wcale nie byłoby lepiej, a już na pewno nie szybciej :)).

Co zatem z PersistentObject może mieć taki samotny wolny strzelec? Kilka ciekawych pomysłów - nie ukrywam, że moje aktualne rozwiązania w kwestii DAO to czysta prowizorka i prędzej czy później będę musiał wypracować jakiś lepszy oraz bardziej ustandaryzowany mechanizm. Pole do popisu mam spore: doświadczenia z C-Z-W, komercyjne projekty służące za poligon doświadczalny - w końcu właśnie tak m.in. OPF i nowy OPD sprawdzam, a cały pakiet działającego kodu i sprawdzonych pomysłów leci później do OpenPB.

Czy pozostałe elementy frameworka mogą się przydać? Owszem, mogą. Po bliższym przyjrzeniu w sumie nieco klas z takiego czy innego ZF można by bez trudu zaadaptować do własnych potrzeb. Podejrzewam jednak, że dla własnej satysfakcji i tak zrobię wszystko po swojemu, bowiem po prawdzie programowanie niskopoziomowe części składowych sprawia mi naprawdę dużą frajdę, a robota, oprócz namacalnych korzyści, powinna być też przyjemna.

Powrót

Na Zyxist.com panuje swoboda wyrażania opinii oraz krytyki pod dowolnym adresem. Jedyny warunek: musi być ona kulturalna i rzeczowa. Na chamstwo, prostactwo lub jawne obrażanie kogokolwiek nie ma tu miejsca i takie komentarze są bardzo szybko usuwane. Jeśli zamierzasz polemizować z treścią wpisu, wpierw uważnie ją przeczytaj.