Witam.
Od kilku lat systematycznie rozwijam swoją aplikację.
Jest ona coraz większa i zachciało mi się odzielić zapytania do bazy od logiki tak aby w przyszłości móc zamienić bezproblemowo mysqla na postgresa albo xmla albo jeszcze cokolwiek innego.
I tu pojawia się problem.
Przeczytałem sporo o wzorcach projektowych (ActiveRecord itp.) jednak one nie za bardzo spełniają moje założenia. W zapytaniach używam wielokrotnych złączeń, funkcji agregujących, funkcji dodatkowych (np. concat() czy date_add() w mysql). Tak więc ich koncepcja generalnie mi nie odpowiada.
Na phppatterns.com widziałem tez rozwiązanie brute forcowe polegające na tym, że tworzy się dla każdego modułu osobną klasę, w której dla każdego zapytania używanego w logice tworzy się osobną metodę zwracającą zestandaryzowany wynik zapytania. Jednak przy wielu zapytaniach klasa taka rozrośnie się niemiłosiernie.
Wszelkie kreatory zapytań też wydają mi się mało optymalne ze względu na bogactwo języka zapytań i na to, że nie może nikt mi zagwarantować, że późniejsze migracje do xmola zachowają kompatybilność np. z frazą gruoupby. Może się więc okazać, że jeżeli napiszę klasę kreatora zapytań implementującą metodę groupby() to potem nie będę miał jak tego przekonwertować do nowego enginu.

Pytanie moje jest więc takie.
Czy macie jakiś sensowny, łatwo dostosowywalny sposób na oddzielenie zapytań od logiki?

php Pro?
Przenoszę na php.


P.S.
AdoDB
Creole
Propel
....

Jak masz chwile -> http://ez.no/doc/components/view/1.1/(file...n_Database.html

Oto cytat z opisu forum php Pro: "Inżynieria programowania w php, strategie budowy aplikacji."
Jak dla mnie oddzielanie warstwy dostępu do danych od logiki aplikacji dotyczy jak najbardziej inżynierii programowania i strategii budowy aplikacji.




Nie chodziło mi o interfejs umożliwiający wykonanie zapytań dla różnych silników baz danych przez to samo ApI jakim jest PDO. Tylko o sposób oddzielenia zapytań od logiki systemu. Czyli o coś takiego abym w module aplikacji nie miał "Select * from ...".

Powtorze za kolega: Propel

A jezeli standardowa bilioteka Ci nie wystarczy to nic nie stoi na przeszkodzie aby ja rozszerzyc o wlasne funckje.

Przecież u podstaw zawsze masz zapytanie do bazy danych, a caly problem polega na tym, ze rozne silniki baz danych stosuja rozne "wersje" SQLa. Dlatego zapytanie select z limitem dla MySQLa nie zadziala dla Oracla czy MSSQLa. Pdo wcale nie rozwiązuje wspomnianego przez Ciebie problemu bo PDO nie jest abstrakcją baz danych w pełnym tego słowa znaczeniu.

Wzorzec aktywnego rekordu nie jest rozwiązaniem stosowanym w celu unikniecia problemu niezgodnosci pomiedzy silnikami baz danych - chyba ze jest częścią tzw. ORMa (Object - Relational Mapping) - np. Propel lub Creole. Sa wygodne w uzyciu i nie wymagaja znajomosci SQLa, ale moim zdaniem jest to rozwiązanie mało optymalne i ograniczone do stosunkowo prostych relacji pomiedzy tabelami w bazie danych.

Alternatywą są rozwiązania typu ADO (Abstract Data Objects) jak ADOdb czy Zend_Db. Tłumacza zapytania na format obslugiwany przez dany silnik bazy. W praktyce nie wyszystko da sie "przetlumaczyc", ale jest to rozwiązanie o wiele bardziej elastycznie niz wyzej wspomniane.

Z kolei klasy typu DAO (Data Access Objects) to wlasnie to co miałeś na myśli pisząc o brute forcowych rozwiązaniach. Tu masz nieograniczona elastyczność i najwieksze mozliwosci optymalizacji. Klasy typu DAO nie ograniczają cie do silnikow baz danych, jako źródła danych. Minusem jest stosunkowo duży nakład pracy przy przejściu na inne źródło danych.

O to mi wlasnie chodzilo. Nie uwzgledniaja wszystkich mozliwosci.



Do tego rozwiazania jak narazie jestem najbardziej przekonany.

Ja stosuje - przynajmniej ostatnio - rozwiazanie hybrydowe tj. ADO + DAO, a jakby do tego dodac kreator prostych zapytan to by nawet wyszedł ORM

Nie wiem czy jest sens tak sie meczyc w perspektywie wejscia w ciagu najblizszych lat obiektowych baz danych