Zastosowanie ormów w biznesie

Witam,
Czy we współczesnym biznesowym świecie tworzy się jeszcze oprogramowanie bez użycia orm, tylko za pomocą np. JDBCTemplate w springu? Pytam, bo strasznie irytuje mnie ociężałość tych frameworków.

Oczywiście, że korzysta się z natywnych zapytań, chociażby do tworzenia raportów gdzie nie można z jakiegoś powodu wprowadzić nowej encji do kodu.

znam pare duzych projektow ktore nie uzywaja orm w ogole i sa wciaz rozwijane bez wiekszych perspektyw na wprowadzenie takowego. w wiekszosci powodem jest wydajnosc, w niektorych zaszlosci historyczne.

@katelx jak mocno ORMy zabijają wydajność w stosunku do takich natywnych zapytań jak np. ww spring jdbc template?
edit
bo w goglu są odpowiedzi tj. http://stackoverflow.com/questions/3731008/performance-difference-of-native-sqlusing-mysql-vs-using-hibernate-orm , ale nie moge znaleźć danych liczbowych

@azalut czy ja wiem czy jakoś hiper zabije ... wręcz przeciwnie, tutaj np: implementacja JPA może mieć jakieś optymalizacje - nie mówiąc już o Cache'u.

Z tego co wiem można ew. się postarać żeby ORM nie był dramatycznie wolniejszy od wersji JDBC/SQL.
Żeby był lepszy wydajnościowo to raczej mało prawdopodobne.

Znajomy pracował przy dość dużym projekcie (system który praktycznie obsługuje każdego w Polsce) i tam z JPA zrezygnowano. Czy ze względów wydajnościowych, czy integralności transakcji czy też ze względu na nieumiejętne stosowanie - tego nie wiem.

@niezdecydowany tak sobie wlasnie pomyslalem
przecież jest cache, second level cache itd. ale mysle ze to zależy od tego jakie operacje się wykonuje. Bo jeśli jakies zapytanie jest wykonywane na tabeli x razy i jest takie samo to cache się zda
ale jeśli pobierane sa dane nie koniecznie często tym samym zapytaniem, w tej samej formie (tzn wykonywane jest wiele, roznych zapytan) to dla większej ilości takich query'ow to może mieć spore znaczenie
ale tylko gdybam bo nie sprawdzałem :)

@azalut ja jestem ch*jowym bazodanowcem - ale ja nie na narzut na zapytania bym patrzył a raczej na to że JPA ma z tyły proxy obiekty i tu szukał problemy z wydajnością, np: cały ten persistence context zaczyna zarządzać 10tyś obiektów, które są tylko i wyłacznie do czytania - wiemy że ich nie edytujemy - tu widzę problem (Oczywiście to nie jest tak że nie ma rozwiązania na to, jest, np: w tym przypadku wystarczy nie odpalać transakcji, em może być ogarnięty i nie tworzyć persistence contextu bleeblebel i tak dalej).

Po pierwsze narzut ORMa nie wynika z tego jak szybko wykona się PROSTE zapytanie, bo to będzie i tak wychodziło na jedno. ORM-y w przypadku prostych zapytań nie są mniej wydajne, bo te kilka milisekund traconych na lepieniu SQLa i później tworzeniu obiektu z ResultSeta i tak będzie traconych przez naszą nakładkę na JDBC by przemapować to co trzeba samodzielnie.

Jeżeli już chcemy mówić o różnicach w wydajności w przypadku ORM vs JDBC to należy przyjrzeć się kilku innym aspektom

• budowanie skomplikowanych JOINów szczególnie w przypadku dużych kolekcji. ORMy nie zawsze "rozkminią", że zmiana kolejności joinów jest lepsza.
• użycie specyficznych dla danego RDBMS rozwiązań np. hintów z Oracle. Da się to zrobić za pomocą ORMa, ale tracimy wtedy interoperacyjność i silnie wiążemy się z konkretną bazą danych.
• cache, lazy loading i temu podobne. ORMy potrafią tym zarządzać i robią to dużo lepiej. Gołe JDBC nie ma żadnych tego typu mechanizmów.
• mapowanie wyników. Tu jest ciekawie, ponieważ dużo zależy od tego co chcemy osiągnąć. W większości przypadków można przyjąć, że nasze rozwiązania będą "nie lepsze i nie gorsze" niż te z ORMa. Czasami jednak ORMy nie potrafią zrobić pewnych rzeczy w mapowaniu albo robią to tak, że lepiej samemu napisać odpowiedni kawałek kodu. Szczególnie dobrze widać to gdy mamy do czynienia ze spartolonym modelem danych (bywa)
• last but not least jak mawiają anglicy - cała obudowa związana z weryfikacją poprawności danych przed zapisem w bazie. ORMy potrafią współpracować "automagicznie" z np. Validation Framework co pozwala nam oszczędzić dość dużo czasu w trakcie kodowania i później testowania.

azalut napisał(a):

@katelx jak mocno ORMy zabijają wydajność w stosunku do takich natywnych zapytań jak np. ww spring jdbc template?
niestety nie jestem w stanie podac konkretnych danych liczbowych, niemniej uzycie hibernate znaczaco spowalnialo prace serwisu nie dajac praktycznie nic w zamian. dwa glowne scenariusze w ktorych uzywamy polaczenia do bazy danych to a) sciagniecie bardzo duzej ilosci danych do cache 1 lub 2 zapytaniami b) generowanie raportow

U nas w projektach główne problemy wydajnościowe z ORM wynikają z programistów....
ORM ogłupia pozwalając na swobodne nawigowanie po grafie obiektów bez myślenia z czym to się wiąże.....
Identyczny algorytm tylko z JDBC sprawia, że programista pisząc kolejne SQL zaczyna myśleć czy aby na pewno nie da się zrobić tego lepiej.

To że Dirty checking zaczyna zwalniać bo w pamięci jest 10 tyś obiektów to nie wina ORM'a a programisty. U nas automatycznie mamy interceptor który sprawdza ile metoda poczytała obiektów i po wyżej 1000 na TX wywalamy wyjątek.

Według mnie dobre wykorzystanie ORM będzie wydajniejsze niż SQL cache, Fetch ready, batche, insert orders, update orders, drity checking na instrumentacji bytecode itp

P.S. Do zobaczenia jutro na DEVOXX

@Szczery z tym:

główne problemy wydajnościowe z ORM wynikają z programistów....

trudno się nie zgodzić ;] Ilu już spotkałem koderów którzy nie rozumieli czemu "wszystko na lazy" albo "wszystko na eager" to złe podejście. Wystarczy też pogooglać ilu ludzi kombinuje jak mieć otwartą sesję w widoku żeby nie dostawać lazy initialization exception / ilu ludzi głowi sie czemu każde zapytanie do bazy trwa kilka minut ;] Albo ilu ludzi nie rozumie co to jest problem n+1 selectów jak sie ma leniwą kolekcję i się ją "inicjalizuje" przez przeiterowanie po niej (serio, ludzie tak robią...)