ORMy są fajne, do momentu kiedy ich błedy nie zmuszają cię do znalezienia się na produkcyjnej bazie, grzebiąc na żywo w SQLu.
Jarek na jednej z prezentacji miał racje. Wyrzucić bazy danych. (upraszczam ikno)
Z drugiej strony nie ma nic przyjemniejszego od momentu oczyszczenia i zamknięcia N kart przeglądarki po godzinach walki z bugiem.
#destroyAllSoftware
nhibernate? tak, zgadzam się, nhibernate najgorszy. Co prawda nigdy nie używałem, ale jak sobie pomyślę o hibernate i pomyślę o .NET i pomyślę że ktoś to połączył...
To powinno być prawnie zakazane. Chyba gorsze było tylko persistence ejb
ORMy są różne - ale hibernate to jest katastrofa. Te same obiekty (o tym samym type) w stanie detached, managed do tego unitialized (kolekcje) i dirty checking to trochę za dużo. W przypadku problemu często trzeba przejechać jakies tony kodu, żeby znaleźc błąd pół kilometra od miejsca gdzie problem się objawia. i wcale nie musi to być w jakimś wielkim monolicie.
@jarekr000000: Dokładnie. Czysty SQL jest częstokroć bardziej oczywisty.
W c# jest fajnie, bo dzięki expressions kompilator w ograniczonym zakresie sprawdza składnię zapytania To tu jest potrzebny jakiś Typed SQL jak JOOQ a nie cały wielki ORM
ORMy i w ogóle frameworki dużo też napsuło krwi, choć przyznać trzeba, że często nam dupe ratują
@KamilAdam: przecież LINQ to jest wręcz TypedSQL. Kiedyś nawet javowcy pisali tutaj że LINQ (query style) za bardzo przypomina SQL from s in stringList where s.Contains("Tutorials") select s;
@mad_penguin: z tym "LINQ do SQL" to taka słodko-gorzka symfonia, bo to jakie wyrażenia są wspierane zależy od konkretnego frameworka. I o ile większość standardowych operacji działa wszędzie, to już bardziej złożone zapytania mogą nam sprawić niespodzianki, w najlepszym wypadku po prostu rzucając wyjątkiem że dane wyrażenie nie jest wspierane.
Pomijając błędy - zawsze mnie cieszy jak mistrzowie Hibernate giną w starciu z implementacją @OneToMany. Serio. Tam są takie małe wredne drobnostki, - mappedBy, cascade, JoinColumn) itd. I siedzą trzy-cztery godziny zastanawiajac się co właściwie robią, testują, CPU trzeszczy od zakladek w chromie. (dobrze, że jest Vlad, bo w końcu na niego trafiają). W SQLu (DDL) człowiek pisze ten związek, dorzuca foreign key i nawet nie wie, że rozwiązał jakiś ultra skomplikowany problem.
@jarekr000000: ale o co chodzi? z czego wynika ta "złożoność" utworzenia relacji pomiędzy obiektami?
hahahah, annotacje to rak, już wolę shadow config files, którymi o wiele wygodniej załatwiam w projekcie wszelkie tego typu sprawy. Moim skromnym zdaniem plik klasy powinien być wolny od tego typu "śmieci", a cały konfig np. encji powinien być trzymany w osobnym pliku, pracuje się i czyta coś takiego o wiele wygodniej, niż przedzieranie się przez kod klasy i annotacje.
@TomRZ: alternatywą dla adnotacji nie są konfigi, xmle i inne zewnętrzne pliki. Albo raczej ja nie widzę różnicy - to i to rak. Xmli, yamli nie lubie nawet bardziej od adnotacji, Choć miało to podejście jedną zaletę, mniej ludzie uprawiali beanów. Adnotacje "compile time" uważam, za całkiem ok, o ile jest ich mała ilość.
Ten decision matrix jest całkiem spoko http://mikehadlow.blogspot.com/2012/06/when-should-i-use-orm.html?m=1 ;)
@karsa moim zdaniem jest średni. 2. Problem z ORMami to nie tylko wydajność, te leaky abstractions to głupie błędy na produkcji. 1. Alternatywą do ORM nie jest ręczne drapanie po bazie (jdbc) są teraz fajne narzędzia jak jooq, slick, etc. 0. Często tam gdzie jednak ORM pasuje...to tak naprawdę nie pasuje SQL.
Ale rozwiązania typu jooq, slick też nie są idealne i możesz skończyć tworząc swoje abstrakcje.
@jarekr000000: ja też nie preferują XML-a, wszelkich formatów opartych o YAMLA, tak samo JSONA ciężko się czyta bez dedykowanego softu, ale to już trochę kwestia gustu. Na szczęście shadow file w takim PHP to po prostu może być tablica właściwości napisana w PHP, lub obiekt klasy \stdClass z publicznymi właściwościami i metodami (callbacks). W Javie pewnie też można podobnie, ale główny nurt poszedł w innym kierunku, jeszcze rozumiem bardzo drobne annotacje, ale kiedy robi się z tego dywan, to już oznaka, że coś jest nie tak.
@Haskell: chciałeś napisać jak u nich będzie wyglądało DR jak powstanie.....
nhibernate?