Czy SQL został wyparty przez ORM'y?

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.

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.

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.

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 ;)

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)

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ówno w przeręblu.

@somekind: to gdzie ORM mają sens?

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.

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.

@robertwadowski: nie wiem jakich ORMów używałeś, ale to wygląda na problem z archiekturą. Ani 15 adnotacji, ani klasy inne niż dwie z ORMa i te mapowane na tabele nie są niezbędne.