[tos-1_buratino]

Po co używać ORM w aplikacji podzielonej na proste mikroserwisy? W czasach kiedy aplikacje były monolitami z setkami modeli ORM miał sens. Ale teraz? Wydzielam warstwę dostępu do danych gdzie mam własny kod SQL oddzieloną od kodu domeny biznesowej i myk.

Odchodzi masa problemów. Choćby N+1 czy debugowanie dlaczego ORM coś źle robi. Łatwiejsze testowanie, prostsza aplikacja jako całość bo odchodzą dość ciężkie biblioteki.

Widziałem produkcyjne aplikacje bez ORM-a z dziesiątkami tysięcy użytkowników i to działa. A jak widzę joina w adnotacjach ORM to rzygać mi się chce od tych abstrakcji nad abstrakcjami.
#programowanie

[Krolik]

@tos-1_buratino: z mojego doświadczenia najlepiej sprawdzają się lekkie ORMy mapujące pojedyncze structy / klasy na wiersze zwracane w zapytaniu lub dane używane w insertach. Eliminują boilerplate a nie mają problemów o jakich piszesz. Np. https://diesel.rs/.

[Krolik]

@tos-1_buratino: a odpowiadając na pytanie po co używać, to dobry ORM załatwia problem wszystkich żmudnych, powtarzalnych konwersji typów pomiędzy typami natywnymi języka a typami bazy danych, weryfikuje statycznie czy Twój program będzie pracował poprawnie z danym schematem danych, daje narzędzia do wygodniejszego budowania zapytań bez SQL injection itp. Ogólnie jest szybciej i bezpieczniej, a wydajność jest identyczna jakbyś korzystał bezpośrednio ze sterownika bazy (a jak nie umiesz poprawnie korzystać ze sterownika

[whoru]

@tos-1_buratino: absolutnie sie zgadzam, ORMy to taka zaszłość mentalna programistów pierwszej dekady tego wieku, że jak tylko widzę ORMa na stosunkowo nowym projekcie to już wiem, że nie był to świadomy wybór tylko przyzwyczajenie. ORMy się sprawdzają, bo ludzie dalej nie potrafią w agregaty (z ang. aggregate root) i umieć nie będą.

[tell_me_more]

@tos-1_buratino: ORM w ogóle ma mało sensu, to relikt czasów kiedy był hajp na OOP.

[MacDada]

Po co używać ORM w aplikacji podzielonej na proste mikroserwisy?

@tos-1_buratino: A czym jest w ogóle ORM? Jest narzędziem. Narzędziem, które służy do zamiany danych z bazy na obiekty.

Więc pytanie brzmi: czy w aplikacji podzielonej na mikroserwisy chcesz używać obiektów enkapsulujących operacje na danych z bazy?

Jeśli odpowiedź brzmi tak, to ORM może być ku temu dobrym narzędziem.

ORM w ogóle ma mało sensu, to relikt czasów kiedy był hajp

[object]

@whoru: co do tego ma ddd?

[Krolik]

absolutnie sie zgadzam, ORMy to taka zaszłość mentalna programistów pierwszej dekady tego wieku, że jak tylko widzę ORMa na stosunkowo nowym projekcie to już wiem, że nie był to świadomy wybór tylko przyzwyczajenie. ORMy się sprawdzają, bo ludzie dalej nie potrafią w agregaty (z ang. aggregate root) i umieć nie będą.

@whoru: ORMy starego typu takie jak Hibernate to zaszłość mentalna. Ale ORM ORMowi nie równy. Jest przepaść między podejściem takim

[markaron]

@tos-1_buratino:

Złożony temat.

Dużo zależy od modelu danych. Jak serwis trzyma dane w bazie nierelacyjnej takie jak: Cassandra, Mongo czy czymś podobnym to ORM nie ma sensu.

Przy prostych i nie wymagających CRUD-ach może się przydać bo wprowadza trochę magii i eliminuje pisanie żmudnego i powtarzalnego kodu. Tutaj mogą się też sprawdzić Micro ORM-y jako alternatywa dla tradycyjnych ORM-ów. Jak sama nazwa mówi nie oferują tych samych funkcjonalności co normalne ORM-y,

[tos-1_buratino]

@markaron:
Jak w DDD masz wyizolowany ORM za pomocą Commandsów to spoko. W razie czego możesz to sobie zmienić jak będziesz chciał.
Ale jak ktoś nie używa DDD, modele robi powiązane na sztywno ORM i dodatkowo trzyma w nich logikę biznesową? I potem są takie legacy projekty z setkami modeli. ORM pomieszany z czystymi sql bo ludzie którzy to napisali sami już nie wiedzą jak to ogarnąć.
Testowalne słabo bo trzeba

[markaron]

@tos-1_buratino:

Pełna zgoda.

modele robi powiązane na sztywno ORM i dodatkowo trzyma w nich logikę biznesową?

Dla mnie to już jest sygnał (logika w modelu dziedzinowym) do zaaplikowania podziału na commands i queries, DDD do tego nie potrzebne oczywiście, chodzi po prostu o sam podział na część odczytową i zapisową z osobnymi modelami. Wiadomo, może wiązać się to z solidną refaktoryzacją rozwiązania, ale to tak jak z ciężkimi chorobami, albo decydujemy