Ze względu na mało kreatywnych tematów na forum php Pro proponuję taką dyskusję.
Które z rozwiązań wydaje wam się korzystniejsze:

ORM
Stricte mapowanie bazy danych do obiektów, które następnie można łatwo wykorzystać w php. Bardzo intuicyjne i wygodne, szczególnie jeśli zaimplementujemy rozwiązanie, które jest w stanie na bieżąco odwzorowywać zmiany w bazie danych (dodatkowe tabele, itd.).
Dodawanie nowej klasy to po prostu stworzenie dodatkowej tabeli, nowy obiekt to rekord.
Wadą jest brak pewnej unifikacji i kłopot z utworzeniem drzewa obiektów, ale myślę, że jest to do obejścia.
Przykład takiego rozwiązania możemy znaleźć w Ruby on Rails.

VFS
Wirtualny system plików też jest ciekawym rozwiązaniem, wprowadzającym jakby dodatkową strukturę w bazie danych, która następnie jest odwzorowywana w postaci obiektów php. Rozwiązanie o tyle dobre, że automatycznie wprowadza nam pewną strukturę drzewiastą, w której mamy nasze obiekty i w jednej gałęzi mogą znajdować się różne obiekty, np. artykuły, komentarze, pliki, itd.
Największą wadą jest to, że wprowadzamy dodatkową "warstwę" modelu, która musi te wszystkie elementy poskładać w całość i przedstawić w postaci obiektów i dodatkowych narzędzi do ich wyszukiwania/pobierania. Jest to nieco mniej intuicyjne, gdyż dodanie nowej klasy/obiektu wymaga znajomości pewnych założeń systemu plików i jeśli nie jest do tego udostępnione dodatkowe narzędzie to mamy problem
Przykładowe drzewo takiego systemu plików: http://www.binarychoice.pl/_images/p28/carbon-uml.gif
Mam nadzieję Seth, że nie masz nic przeciwko

Oba rozwiązania mają swoje minusy, ja planowałem zaimplementować w swoich projektach VFS, ale przyglądając się prezentacjom Ruby on Rails byłem mile zaskoczony prostotą ich ORM-a. Chyba najlepszym rozwiązaniem będzie jakieś połączenie obu rozwiązań.

Cóż więcej mogę powiedzieć - do dyskusji koledzy

Problem z unifikacją? Podejrzewam że jest to dopiero przed dobrymi ORM'ami w php ale juz pod java (hibernate) to baza dostosowywuje sie do modeli. Piszesz najpierw klasy które dopiero później parsujesz na odpowiednie modele.
Drzewo obiektów? Przeciez do tego wystarczy relacja one-to-many itp.

Gdyby tylko w php bylo wspierane programowanie Aspektowe (AOP) nie bylo by problemow (mozna bylo by z poziomu AOP mapowac klasy na dane w bazie), a tak najpierw trzeba robic struktury w bazie aby pozniej tworzyc dynamicznie klasy i obiekty, ktore beda sie przekladac na dane w bazie (mam nadzieje, ze to ne brzmi jak maslo maslane ).
Przy tamtej struktorze bazy zakladam, ze jest ona szkieletem, a zarazem dostawca danych (instancje obiektu) ale i tak i tak trzeba na jej podstawie wygenerowac klasy w php aby moc latwo sie do nich dobrac.


P.S.
Strukture ktoral podales matid raczej bym zakwalifikowal do ORM bo celem jej nie bylo stworzenie virtualnego systemu plikow.

Mi bardzo podobają się rozwiązania ORM ponieważ dają one na prawdę dużego kopa. Nie miałem styczności w praktyce z VFS, ale prawdę mówiąc patrząc na ORM a VFS nie widzę dużej różnicy, chociaż wydaje mi się, że mapowanie jest jakby bardziej zgeneralizowane, nie narzuca struktrury i zależności.
W ORM myśli się w kategorii obiektu tak jak nakazuje idea projektowania obiektowego a nie w kategorii plik/katalog jak przy VFSie.
Chociaż prawdę mówiąc wzorzec ActiveRecord w najprostszej postaci jest o wiele prostszy niż VFS, który polega na kompozycji.
W ORM dzięki zastosowaniu wzorca Foregin Key Mapping możemy bez problemu zrobić sobie kompozycję łącznie z self-reference.
Foregin Key Mapping umożliwia z kolei zastosowanie wzorca LazyLoad, ponieważ wiemy na jakiej podstawie dołączać kolejne rekordy, jak wygląda związek pomiędzy nimi.
Zastosowanie ORM daje możliwość stworzenia na prawdę złożonego CRUDa, a stąd niedaleko już do zaprojektuj bazę i kliknij generuj (przykład?) . Sam zastosowałem parę razy Propela (wzorowany na innym ORM dla Javy) i muszę powiedzieć że dzięki niemu cały kod jest bardziej przejżysty, nie muszę się męczyć z tworzeniem modeli i tak dalej, ponieważ kod mi się generuje ze struktury sam.
Co do tworzenia tabel na podstawie klas - myślę że to nie jest problem - zastosowanie Reflection API + odczyt komentarzy php Doca i mamy gotowce, chociaż działanie w tą stronę wydaje mi się trudniejsze. Z resztą dla Javy jest X-Doclet który wspomaga pracę z wieloma narzędziami, w tym i z Hibernate.


Jeśli ktoś poda przykład implementacji VFSa mogę dyskutować dalej..

Witam,

A ja mam pytanie - co ma piernik do wiatraka

ORM - definicje znamy - badz co badz jest to specyficzny layer bazodanowy - nie ukrywajmy - niczym wiecej to nie jest i tyle.

VFS - nie wiem co Wy pod tym slowem rozumiecie, ale jak dla mnie jest to metoda składowania danych (!)

Czemu temat jest ORM vs VFS

IMHO czyms co mozna po czesci nazwac VSF w waszym rozumieniu jest modul zarzadzania trescia ezPublisha gdzie dowolny obiekt mozna by jakoby nazwac plikiem. Calosc grupujemy w foldery, mam strukture drzewiasta i tyle.

Co do samego wirtualnego systemu plikowego - napisanie czegos takiego jest zajeciem nie ukrywajmy trudnym. Wg mnie pisanie czegos takiego na MySQL-u < 5.0 lub bez PostgreSQL jest cokolwiek glupie Pojecie wydajnosci zanika czego mamy doskonaly w ezPublishu ktory jak wiemy jest powolna krowa ( ktora duzo mleka daje i duzo ryczy ). Natomiast na lepszych bazach mozna sie pobawic - majac podzapytania czy tez widoki dostep do danych moze byc zdecydowanie szybszy - dla mnie wydajne rozwiazanie to takie ktore pozwolic pobrac liste plikow z danego folderu jednym zapytaniem pozwalajac jednoczesnie na sortowanie tych plikow w obrebie bazy - dla slabszych baz jest to niemozliwe. VSF ma tez swoje wady - glownie tutaj chodzi o kwestie relacji pomiedzy obiektami jak np. kategorie obiektow.

Pozdrawiam

Tutaj się nie zgodzę chyba, że słowo specyficzny ma szerszy zakres niż mi się zdaje. Jest mu stawiany zupełnie inny cel niż takiemu Ado DB czy też Creole.
ORM ma dawać namiastkę obiektowej bazy danych, poniekąd ją emuluje. Uwalniasz się od zapytań - możesz ich wogóle nie pisać a korzystać tylko z obiektów typu powiedzmy Criteria. Przy użyciu zwykłego DB Layera nie możesz myśleć w kategorii obiektów, dalej jesteś przywiązany do zapytań SQL..

Czy rzeczywiście ORM pozwala uwolnić się od SQLa? Ja jakoś nie jestem do tego przekonany. Z jednej strony mam bardzo małe doświadczenie w używaniu tego typu narzędzi, z drugiej strony moje doświadczenie to raczej duże bazy danych i tuningowanie skomplikowanych zapytań. Joiny kilkunastu tabel, wielokrotnie zagnieżdżone podzapytania, funkcje hurtowni danych, procedury PL/SQL... takie rzeczy. I pomimo dostępności naprawdę rozbudowanej biblioteki pozwalającej "zbudować" zapytanie SQL z obiektów Criteria (i wielu innych), nie dało się z tego korzystać, bo powyżej pewnego poziomu zakręcenia SQL nie daje się go przełożyć na obiekty.

Z doświadczenie zdobytego w hibernate wiem że czasami trzeba użyć hql'a.

Masz racje. Zapytania nie musza byc nawet, az tak zakrecone, ale tu nie chodzi o wpelni zoptymalizowane pod katem konkretnego silnika bazy, wysoce wydajne zapytania. Jesli sie mysli o prostych, w miare uniwersalnych, najczasciej powtarzajacych sie zapytaniach to calkowita przesiadka na obiekty moze byc calkiem realna. Moim skromnym zdaniem zapytania typu INSERT i UPDATE w 99% moga byc budowane w ten sposob. Z SELECTAMI pod tym wzgledem jest duzo gorzej. Niekiedy prosciej recznie napisac zapytanie niz wgryzac sie w logike obiektowych kreatorow zapytan.

Tworzysz klasę z odpowiednią metodą dziedziczącą z określonego peera, i korzystasz z metody hydrate - nawet najbardziej zakręcone pytanie możesz samodzielnie przełożyć na obiekty. A jeśli już wchodzimy w zapytania bardzo niestandardowe, zakręcone etc. - je zwykle pisze osoba znająca konkretną bazę danych na wskroś, a często się zdaża, że nie jest to ta sama osoba która tworzy system. Do programisty należy w takim układzie dopisanie kilkunastu lini by uzyskać efekt..
Można również korzystać z widoków, które w chwili obecnej obsługuje większość baz i wykonywać zapytania na nich - nie ma przecież problemy by stworzyć widok, a jeśli umie się stworzyć zakręcone pytanie to stworzenie reguł do obsługi widoku i wyzwalaczy nie powinno być problemem.

To ja tez dozuce swoje 5 groszy.

@splatch

Z tym to akurat sie nie zgodze. Kopa w sensie pisania aplikacji tak, ale nie wydajnosciowego.
Wlasnie podejscie ORM w pewnym sensie narzuca stuktury i zaleznosci, jak juz @matid pisal wykorzystywane jest to w Ruby on Rails, przyklad np Cake. Z jednej strony ulatwienie i wygoda a z 2 strony pewne ograniczenie, to co pisal @hawk.

Kolejna rzecza rozumienie ORM jako DB Layera po niekad jest bledne, jak wiadomo DB Layer jest w pewnym sensie translatorem zapytan SQL gdzie przy bardziej zlozonych projektach jak i bazach sie nie sprawdza.

Troche odbiegajac od tematu, porusze tutaj kwestie DB Layera jako tlumacza wielu dla wielu baz. Przy takim zalozeniu ORM jest to najgorsza rzecza jesli chcemy wykorzystywac w naszym projekcie wiele baz danych, poczawszy od MySQL a skonczywszy na ORACLE. Wtedy na sile przekladamy ten sam kod na wszystkie bazki. Wtedy na pewno dobrym podejsciem jest odzielenie od siebie klas zaleznych od bazy danych, moze troche to tak niezrozumialem napisalem ale jesli korzystamy z ORACLE to wykorzystajmy w pelni mechanizmy jakie oferuje np PLSQL, czy dla PG plpgsql.

Podobnie uwazam jak @hawk ze przy zlozonych projektach wymagajacych "potezniejszych" baz danych ORM sie nie sprawdza, bardziej mozna powiedziec "nie da sie go wykorzystac" poniewaz pewnych obiektow nie da sie przelozyc na baze danych. Dla projektow bardziej zlozonych jesli chodzi o DB, wyzbywam sie wszelkich narzucen DB Layerow, wtedy taka klasa/zbior klas sluzy jedynie aby wygodnie wyciagac dane. Trudno jest wtedy/niemozliwe przelozyc np wywolanie funkcji pl/sql (hehe).

Istnieją implementacje AOP dla php.
Coś mi się obiło o uszy, że trwają pracę na rozszerzeniem implementującym AOP, co będzie szybsze.

http://phpaspect.org