Zastosowanie ormów w biznesie

Odpowiedz Nowy wątek
2015-06-17 13:24
Pijany Młot
0

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.

Pozostało 580 znaków

2015-06-17 14:40
0

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.

Pozostało 580 znaków

2015-06-17 15:52
0

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.

Pozostało 580 znaków

2015-06-18 17:24
0

@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/ques[...]-mysql-vs-using-hibernate-orm , ale nie moge znaleźć danych liczbowych

edytowany 1x, ostatnio: azalut, 2015-06-18 17:27

Pozostało 580 znaków

2015-06-18 17:40
0

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


"Perhaps surprisingly, concurrent programming isn’t so much about threads or
locks, any more than civil engineering is about rivets and I-beams."

Pozostało 580 znaków

2015-06-18 19:05
0

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.


Szacuje się, że w Polsce brakuje 50 tys. programistów

Pozostało 580 znaków

2015-06-18 19:13
0

@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 :)

Pozostało 580 znaków

2015-06-18 19:40
0

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


"Perhaps surprisingly, concurrent programming isn’t so much about threads or
locks, any more than civil engineering is about rivets and I-beams."

Pozostało 580 znaków

2015-06-18 22:07
4

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.
okej, ale w sumie nie daje mi spokoju co napisałem wyżej - fakt zarządania obiektami i tworzenia dla nich proxy obiektów przez np: entity manger może spowodować problemy z wydajnością ? bo np: w pro jpa wspominają o tym jako o dobrej praktyce żeby właśnie starać się wskazywać które obiekty nie będą modyfikowane(właśnie np: przez brak transakcji) - niezdecydowany 2015-06-18 22:10
Transakcyjność to osobny problem. Generalnie nie powinno się zakładać transakcji na operacjach niemodyfikujących z powodu narzutów jakie za tym idą. Jednocześnie można to ogarnąć z znacznie prostszy sposób poprzez separację operacji typu query (odczyty) i command (zapisy). - Koziołek 2015-06-18 22:22
wspominali o tym :) - niezdecydowany 2015-06-18 22:28

Pozostało 580 znaków

2015-06-21 11:28
0
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

Pozostało 580 znaków

2015-06-21 11:54
1

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 napewno 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

edytowany 2x, ostatnio: Szczery, 2015-06-21 13:28

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0