ORM vs VFS, Zastostowanie ORM i VFS w projektach Opcje

[matid]

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 (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
Przykładowe drzewo takiego systemu plików: http://www.binarychoice.pl/_images/p28/carbon-uml.gif
Mam nadzieję Seth, że nie masz nic przeciwko (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

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 (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[SongoQ]

To ja tez dozuce swoje 5 groszy.

@splatch

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.

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).