Cześć, nigdy nie używałem żadnego prawdziwego ORMa i zastanawiam się nad sensem nauki np. Entity Framework. Wiem, najlepiej by było sprawdzić na własnej skórze, ale po co, skoro wokół tylu programistów? :)
Więc tak. Czytam artykuły i jak zwykle. Jedni są za, inny przeciw. A jak to jest z Wami? Macie jakieś dobre/złe wspomnienia z tym związane? Używacie chętnie ORMów, czy raczej staracie się ich unikać?
ORM jest fajny jako zabawka do małych projektów
ORM się nadaje do niektórych projektów, a do innych nie (dobry do szybkiego prototypowania)
Za wolny - Nie używam. Wolę sam pisać stary, dobry SQL
W laravelu korzystam tylko z orma (eloquent) Dużo szybciej pisze się kod, a czas to pieniądz. Sam eloquent ma wbudowane bardzo fajne mechanizmy które potrafią robić takie zapytania jak bym sam pisał ręcznie więc nie widzę sensu się męczyć skoro mogę robić to szybciej i nie martwić się o sql injection.
Wolę ORM'a. Ułatwia wiele rzeczy. Jak się odpowiednio bazę zrobi (ponazywa tabele i klucze etc...) to nawet mapowania w nHibernate nie trzeba robić, bo wszystko automaper ładnie objedzie. Wystarczy tylko klasy encji utworzyć, wskazać ORM'owi, ktory namespace ma być mapowany i ma się wszystko.
Tak, tak zdecydowanie wolę ORM'a, a nawet jak czegoś nie ogarnie to i tak wygodniej sie takiego native SQL'a przez nHibernate przesyła niż przez zwykle ADO. Wywołanie procedur skladowanych ładnie można puścić... no bo po kiego wszystko pisać ręcznie.
Zależy od zastosowań. W systemach gdzie logika jest mocno oparta na relacjach ORM nie ma racji bytu z uwagi na wydajność. W innych jak najbardziej, bo znacząco przyspiesza pisanie aplikacji (szczególnie Code-First).
Juhas napisał(a):
Więc tak. Czytam artykuły i jak zwykle. Jedni są za, inny przeciw. A jak to jest z Wami? Macie jakieś dobre/złe wspomnienia z tym związane? Używacie chętnie ORMów, czy raczej staracie się ich unikać?
Trzeba być dzieckiem albo fanatykiem, żeby być albo za, albo przeciw w tak ogólnej kwestii. ORM to narzędzia, narzędzi używa się w konkretnym celach.
Sensowne ORMy pozwalają:
Natomiast ORMy nie mają sensu w przypadku
No i jak to w przypadku narzędzi bywa, potrafią być niebezpieczne i zaszkodzić, np. gdy:
Tak więc, to nie jest nawet tak, że można ORMa dobierać do jednego projektu, a do innego nie. ORM może pasować do niektórych zadań w projekcie, a do innych w ogóle. Architektura to nie bzdura.
To zależy od projektu. Jeśli chodzi o Javę, to spróbuj JOOQ jako alternatywy (https://www.jooq.org/). W przypadku ORM-ów można trafić na ścianę (lub ORM utrudni nam zadanie zamiast ułatwić), gdy mamy bardziej skomplikowany problem do rozwiązania. Jeżeli celujemy w dobry performance, to też lepiej zrezygnować z ORM-a. Jeżeli mamy prostego CRUD-a i performance nie jest kluczowy, to wtedy ORM będzie ok.
A jak to jest w przypadku, gdy jakiś obiekt jest zapisany w bazie w kilku tabelach. Żeby pobrać go, trzeba zrobić odpowiednie JOINy. Czy ORMy w tej sytuacji dają radę?
Wypowiem się tylko o Hibernate - przy dużych projektach koszty przekraczają zyski.
@Juhas spokojnie można robić joiny. W nh masz do tego mechanizm np.: QueryOver<Class>().JoinQueryOver(c=>c.CollectionInClass). Czy jakoś tak... teraz nie mam tego przed oczami. Domyślnie robiony jest join po kluczach głównym i obcym czyli Id i ForeignTable_Id.
Zawsze możesz też puścić przez ORM zwykłe zapytanie z joinami po czym tam chcesz i zrobić z tego projekcję i masz wynik.
No i w relacjach 'many to many' robiąc select'a przez ORM'a nie musisz nawet odpytywać tabeli proxy. Mechanizm sam porobi odpowiednie joiny.
Juhas napisał(a):
A jak to jest w przypadku, gdy jakiś obiekt jest zapisany w bazie w kilku tabelach. Żeby pobrać go, trzeba zrobić odpowiednie JOINy. Czy ORMy w tej sytuacji dają radę?
ORMy potrafią zapisać jeden obiekt do wielu tabel i nie musisz sam ręcznie wołać żadnych JOINów.
Potrafią nawet zapisywać hierarchie obiektów do jednej albo wielu tabel (zależy jak skonfigurujesz).
Tak jak napisał @somekind trzeba być fanatykiem żeby uważać że coś jest albo super i do wszystkiego albo beznadziejne i do niczego (w informatyce).
Tak ORM mogą być czasami problematyczne i potrzebować dużo czasu ale to często wynika z niewiedzy developerów którzy z tych ORM-ów korzystają.
I fakt że korzystasz z ORM nie oznacza że nie możesz pisać SQLi natywnych, np. możesz robić operacje zapisu/aktualizacji/usuwania ORMem a dużo przenieść selectów na natywny SQL,nie widzę żadnego problemu :D
Najpierw człowiek się uczy SQL, potem ORM, potem gdzie tego ORM-a ograniczać albo nie używać (np. w raportach).
Oprócz tego masz jeszcze dwie ścieżki ORM-owe:
https://www.kenneth-truyers.net/2013/12/05/introduction-to-domain-driven-design-cqrs-and-event-sourcing/
https://martinfowler.com/bliki/CQRS.html
Chodzi o to, że w raportach SQL jest prostszy i wydajniejszy?
ORMy pozwalają na szybkie prototypowanie.
SQL pozwala na większą kontrolę.
ORMy są w każdym frameworku inne i trzeba się ich uczyć od nowa po przejściu na nowy framework
SQL jest podobny wszędzie (chociaż też są jakieś różnice między bazami danych), ale jednak nie ma tak, że od nowa się uczysz za każdym frameworkiem. Ba, nawet język programowania możesz zmienić w międzyczasie, a zapytania pozostaną te same.
SQL i tak musisz znać, nawet jak używasz ORM (nie da się chyba jechać tylko na ORM).
A możesz nie znać żadnego ORMa i jechać na SQL
SQL jest prostszym rozwiązaniem.
ORM to bardziej złożone rozwiązanie, bo ORMy ci enkapsulują cały SQL i mapują do obiektów, więc z konieczności zawierają o wiele bardziej złożone abstrakcje)
Ale za to ORM jest łatwiejszy w obsłudze, na SQL trzeba się znać.
ORMy mogą się ładnie integrować z frameworkiem, którego używasz (przynajmniej tak jest np. w Django).
SQL musisz ręcznie sobie zintegrować z kodem.
itp. jest wiele różnic w sumie.
ORM pozwala przede wszystkim na to że nie trzeba pisać bardzo dużej ilości SQL do insertów,updatów itd.
Jak pisałem ORM jest dużo wygodniejszy przy modyfikacji danych, a SQL zawsze możesz napisac dodatkowe do selectów ;)
Z tego, co wnioskuję z Waszych wypowiedzi, wynika że:
Jeśli znam SQL i nie mam dużej ilości klas do zapisu, to nie zaprzątać sobie głowy ORMami. Czy to rozumowanie się zgadza?
Zdefiniuj niewielką ;)
Coś około 5 - 7. Chociaż na razie jestem jeszcze właściwie przed faktyczą fazą projektowania, ale myślę, że 10 nie przekroczy.
ORM jest po prostu wygodny i nie widzę sensu dziergania samemu zapytań SQL jeżeli istnieje narzędzie które zrobi to za nas (nawet jeżeli jest to okupione pewnym narzutem na wydajność). Inną kwestią jest to, że oba sposoby można tak "wycudować", że będą działały fatalnie. Kwestia wiedzy i doświadczenia. Każdą rzecz można spartolić.
LukeJL napisał(a):
SQL i tak musisz znać, nawet jak używasz ORM (nie da się chyba jechać tylko na ORM).
Oczywiście, że się da i to jest faktyczny problem. Bo na ORMy narzekają głównie ludzie, którzy próbują ich używać do wszystkiego pchając encje do GUI i nigdy nie zastanawiając się jaki SQL jest generowany pod spodem.
Juhas napisał(a):
Jeśli znam SQL i nie mam dużej ilości klas do zapisu, to nie zaprzątać sobie głowy ORMami. Czy to rozumowanie się zgadza?
Ja też znam SQL, ale bardziej szanuję swój czas. Poza tym, klepanie setek linii identycznych zapytań jest nudne jak obserwowanie rosnącej trawy.
No, i mi nikt nie płaci od linijki.
@scibi92:
lol, słyszałem, że programiści się obrażali o nazwanie informatykami, ale, że teraz to słowo programista stało się obelgą to nie wiedziałem :)
Ale w sumie developer brzmi tak angielsko, więc lepiej, coś jak CEO zamiast prezes :D
Co do samych ormów, to jak się wie co się robi, to są fajne.
Ankieta jest bardzo tendencyjna, bo zakłada istnienie tylko dwóch opcji:
Po drodze są mniej skrajne rozwiązania jak np jOOQ, które jest otypowanym SQLem.
Ja używam Scali, a dla niej jest bardzo fajna biblioteka Slick: http://slick.lightbend.com/doc/3.2.0/queries.html#joining-and-zipping W kilku linijkach robię np joiny i wyciągam kolekcje obiektów, a całość jest statycznie otypowana.
I oczywiście istnienia type providersów też nikt nie uwzględnia :)
DROP DATABASE i problem załatwiony.
Ale serio - albo potrzebujesz robić skomplikowane raporty i wtedy np. JOOQ np. lepiej działa od JPA.
Albo nie masz komplikowanych zapytań z group by, window etc. to wtedy nie potrzebujesz bazy danych.
ORM jest dobry żeby zmapować sobie wynik selecta z joinami na graf encji, żeby nie pracować z płaskimi tabelami, ale to wszystko.
Polecam lekturkę explicit locking w postgresie i w ogóle całego rozdziału poświęconemu współbieżności, zobaczcie ile się traci używając hibernate
https://www.postgresql.org/docs/current/static/explicit-locking.html
Część logiki musi być napisana w javie ale to musi być ścisła współpraca javy z bazą.
Warstwy abstrakcji pomagają wymieniać komponenty i ułatwiają pracę (ukrywają szczegóły) ale tracimy specyficzne ficzery, coś za coś.
Gdybym miał napisać aplikację bazodanową i ręczyć za nią głową, to prędzej bym logikę napisał w PL/SQL niż ufał ORMom
Entity Framework Method syntax vs Query syntax
Tu sobie trochę podyskutowałem. Ogólnie nie lubię ORMów, ale argumenty strony przeciwnej w w/w wątku są całkiem merytoryczne.
terefere napisał(a):
Warstwy abstrakcji pomagają wymieniać komponenty i ułatwiają pracę (ukrywają szczegóły) ale tracimy specyficzne ficzery, coś za coś.
Więc do typowych zadań wystarczy ORM, a tam gdzie trzeba czegoś specyficznego bądź zależy nam bardzo na wydajności używa się bazy. To takie proste! Te dwa światy też są proste do połączenia w jednej aplikacji, sam to robiłem wielokrotnie. Nie rozumiem czemu tylu ludzi myśli czarno-biało i koniecznie musi się opowiedzieć po którejś ze stron, a potem używać tylko jednego podejścia. To nieprofesjonalne.
student pro napisał(a):
Gdybym miał napisać aplikację bazodanową i ręczyć za nią głową, to prędzej bym logikę napisał w PL/SQL niż ufał ORMom
Zapewne też łatwo udowodniłbyś poprawność algorytmów przy pomocy testów. Czas wytworzenia też miałbyś zapewne szybszy niż ktoś rozsądnie stosujący ORMa.
Ostatnio znowu wracamy do OrmHate. Ja raz użyje a raz nie.
A co do nienawisci do ORM to zostawie to tutaj.
https://martinfowler.com/bliki/OrmHate.html
Coraz częściej tez widac NoSQLe w projektach.
Można mieć też takie podejscie:
https://paper.dropbox.com/doc/Our-code-is-fine-but-our-SQL-is-great-QyJ9idATiWVYssejUcep9
