Wątek przeniesiony 2020-01-08 23:41 z przez somekind.

Czy SQL został wyparty przez ORM'y?

6
Shalom napisał(a):

Chyba tylko w CRUDach albo i nawet nie tam. ORMy są od lat w odwrocie, kiedy okazało się że zwyczajnie sie nie sprawdzają.

No bez przesady ;) Często jak ktoś tak mówi, to duża część ludzi ma w myślach powrót do sklejania stringów w kodzie, chodzeniu po datasetach i konwersji typów danych na natywne dla języka łącznie z kodowaniami. To za daleko idący odwrót. Po prostu nie myśli się o bazie już jako o stałej warstwie prezystencji pomijając czym ta baza jest. Moim zdaniem ORM ma się dobrze jako ogólnie DAL, czy nawet takie ef robi dobrze, za DAO. Po prosty trzeba mieć świadomość, żeby nie targać z pół bazy do kontrolera, bo ktoś w repo wymyślnie zwraca IEnumerable całej dziedziny, czy postanawia sobie raporty liczyć metodami w kodzie i targa nawet więcej niż pół bazy. Ciekawe też, są przypadki struktur tabelarycznych przypominających graf pełen i tak napisanie "repozytorium", że chcąc wyciągnąć nazwę klienta a targa klienta, z oddziałami, zamówieniami, osobami kontaktowymi etc.

Żeby tak się nie działo, należy projektować aplikacje z głową. Np. zwracać z bazy tylko 1 klienta bez relacji i mieć od tego metodę, lub zwrócić dane tylko do tabeli, żeby zrobić kartotekę klientów i to tez z jakiego zakresu dziedziny, czyli stronicować. Raporty czy cięższe analizy pisać w SQL i zwracać procedurą jak z tabeli czy widoku, ale za pomocą ORM. Warto też projektować płaską strukturę bazy danych i ją normalizować.

Rezygnacja z ORM to znów problemy z transakcjami, mapowaniem na obiekty, konwersją typów, sklejaniem stringów w n miejscach ( no można zamknąć wszystko w DAO, ale tak się nie dzieje jak można "legalnie" napisać SQL, no a, że nie w tej warstwie...).

Zawierzanie w magiczność ORM, że Dev sobie napisze wesołą twórczość, a ORM magicznie nie wytarga połowy bazy, nie zaciągnie zależności etc. etc. można włożyć pośród bajki, ale nie należy cofać się 30 lat do tyłu tylko używać ORM jako narzędzie świadomym jego ograniczeń (jak każdego narzędzia).

6

Rezygnacja z ORM to znów problemy z transakcjami, (...) sklejaniem stringów w n miejscach

Co to za bzdury? o_O Jedno z drugim nie ma nic wpsólnego. Zapewniam cię że są biblioteki które pozwalają wygodnie korzystać z sqlowych baz danych, a jednocześnie nie dają raka jak hibernate i pozwalają wygodnie kontrolować zapytania.

2
Shalom napisał(a):

Rezygnacja z ORM to znów problemy z transakcjami, (...) sklejaniem stringów w n miejscach

Co to za bzdury? o_O Jedno z drugim nie ma nic wpsólnego. Zapewniam cię że są biblioteki które pozwalają wygodnie korzystać z sqlowych baz danych, a jednocześnie nie dają raka jak hibernate i pozwalają wygodnie kontrolować zapytania.

Nie bzdury, a doświadczenie. Jak mamy juniora i nie mamy wypracowanych standardowych bibliotek czy sposobów i przykładów użycia, to junior wchodzi w kurs z sieci. Tam jest przykład jak użyć. Potem widzę na CR

connection.Open();
var transaction = connection.BeginTransaction();
var command = new Command("select * from demo", connection, transaction))
var reader = command.ExecuteReader();
  while (reader.Read())
 {
    var values = new object[reader.FieldCount];
    reader.GetValues(values);
    Console.WriteLine(string.Join("|", values));
  }

Ofc po co using, czasami widzę taką metodę, gdzie transaction przyleci z parametru etc. Jednak trudniej zrobić sobie krzywdę używając ORM, poza targaniem połowy bazy co łatwo wykryć i naprawić, a gubiące się transakcje to wrzód na tyłku. Już widziałem taki spaghetti, że tylko logami na produkcji śledziło się, co trzeba zrobić, żeby trafić na nie otwartą transakcje, lub gdzie wycofanie idzie źle idzie, bo ofc. nie stosowano UnitOfWork, a transakcje traktowano, jako mechanizm logiki biznesowej. Z ORM trudniej strzelić sobie w stopę i już wolę optymalizować syf w linq, lub dopisać do "repo" czy innego DAO metodę, która zwróci tylko odpowiednie dane, niż śledzić tygodniami transakcje. Zresztą pokaż przykłady tych dobrych bibliotek, co załatwiają, zarządzanie transakcjami, parametrami, mapowaniem danych, konwersją ... i żeby nie można było to nazwać ORM.

4

Zresztą pokaż przykłady tych dobrych bibliotek, co załatwiają, zarządzanie transakcjami, parametrami, mapowaniem danych, konwersją ... i żeby nie można było to nazwać ORM.

Ot choćby Spring JDBC Template? :) Nie ma tam żadnego ORMa, przy odpalaniu query podajesz funkcje które mapuje row na obiekt, transakcje są automagiczne, jest bindowanie nazwanych parametrów, czego chcieć więcej?
ORM na sens w Generic CRUD gdzie chcesz faktycznie wyciągać całe tabele z bazy. W normalnych aplikacjach zwykle jednak cię to nie interesuje.

1

Nie znam tej biblioteki, ale pewnie dlatego,że to ze świata Javy, a ja właśnie siedzę, w .NET ;) Zobaczę na jakiś przykład co to jest. Co do stwierdzenie, że w CRUDach jest sens - no na pewno jest, a jednak większość oprogramowania obecnie to jakiś rodzaj cruda, więc w tym kontekście ORM żyje. Jeśli mamy aplikacje, która serio tylko czasami składuje dane, lub pobiera je z 1-2 tabel i to nie wszystkie to w takim przypadku mógł bym napisać nawet tego sqlcommanda i wyciągnąć dane, ale jeśli wyciąganie danych i wkładanie ich to ponad 50% operacji, wtedy ORM jest niezastąpiony. Jeśli CRUDów jest serio spooooro to twierdzenie, że ORM są w odwrocie jest nadużyciem. Niemniej jak wcześniej wspomniałem, warto znać SQL, właśnie szczególnie jak pisze się w ORM, a poza tym są firmy które programują w stylu lat 80-90 i tam takie coś jak ORM to dziwaczenie ;)

0

Są różne DSLe też które pozwalają na łatwe i przyjemne selecty bez kochania się z różnymi magiami typu dirty checking.
W Springu możesz podpiąć takiego JOOQ pod transakcje Springowe i możesz korzystac z TransactionTemplate (albo jak 99% niestety robi korzystając z @Transactional)

14
Shalom napisał(a):

Chyba tylko w CRUDach albo i nawet nie tam. ORMy są od lat w odwrocie, kiedy okazało się że zwyczajnie sie nie sprawdzają.

Oczywiście, że się sprawdzają - jeśli używa się ich rozsądnie i tam, gdzie ma to sens.

Niestety programiści zawsze każdy mechanizm czy narzędzie próbują traktować jako silver bullet i używać go wszędzie, tak jest z interfejsami, testami jednostkowymi, ormami, kontenerami IoC, mockami, mikroserwisami itd. Najpierw ktoś tworzy narzędzie służące do jednego celu, potem to narzędzie obrasta milionem ficzerów pobocznych stając się już tak skomplikowane, że już wszyscy zapominają jaki był jego pierwotny cel, a potem niespodziewanie okazuje się, że utrzymanie takiego narzędzia jest zbyt trudne i kosztowne. No i co należy zrobić? Ogarnąć się i zacząć używać z rozsądkiem tego, co faktycznie ma sens? Oczywiście, że nie! Trzeba znaleźć nowy silver bullet.
I tak się ta branża kręci jak g**no w przeręblu.

0

@somekind: to gdzie ORM mają sens?

4

Jak dla mnie, to wszędzie tam, gdzie nie ma jeszcze bazy danych ale jest potencjalnie rozbudowany persistence model, który będzie się często zmieniał podczas developmentu, a zapis/edycja będą często wykonywanymi operacjami. (Często, nie koniecznie wsadowo, po prostu nie chodzi o rzadko zmienne dane.)

No i generalnie, użycie (bądź nie) ORMa to powinien być szczegół implementacji działania warstwy danych, nie główna decyzja architektoniczna projektu.

4

Ormy to zło wg. mnie. Nieraz musiałem się przy nich nagimnastykować żeby coś wychodzącego po za CRUD zrobić. SQL jest dużo bardziej przyjazny dla mnie - jasno pokazuje intencje a nie piętnaście anotacji definiujących jakieś zachowania albo kilka klas by zrobić SELECT, INSERT, UPDATE lub DELETE.

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