Cześć!
Ostatnio wpadł mi w ręce artykuł dot. EF vs Nhibernate... I tak się zastanawiam, czy wielką zbrodnią jest w dalszym ciągu używanie ADO.Net.
Moje początki sięgają jeszcze MS Access 97/2000 gdzie wykorzystywałem VBA. Później przeszedłem na VB.Net i zacząłem używać właśnie ADO. W wyżej wspomnianym artykule zarzucono EF m.in. tworzenie zbyt złożonych zapytań SQL. Ja w ADO sam tworzyłem zapytania i nie stanowi to dla mnie większego problemu. Stosując ADO jestem ograniczony (jeśli chodzi o zapytania) możliwościami serwera bazy danych, a w przypadku dodatkowych nakładek dodatkowo dochodzą ograniczanie narzucane przez nie same. W efekcie na końcu i tak jest zapytanie SQL które jest wysyłane do serwera... W ADO mam to od ręki... A przecież zarówno EF jak i NHibernate (chyba) wzorują się na ADO.
Pozdrawiam
RM
Tu nie chodzi o żadne wzorowanie się a o to że oba frameworki używają ADO.Net. I jak najbardziej warto z nich korzystać bo ułatwiają pracę. Zaraz mogą się tu zjawić maniaki krytykujące EF ale zapewniam że nie ma większego znaczenia który użyjesz.
Bardziej chodziło mi o to żeby pominąć zarówno EF jak i NHibernate i dalej stosować samo ADO. Jakiś czas temu trafiłem na tutoriala, który został bardzo skrytykowany za to że w aplikacji MVC wykorzystywał właśnie ADO czyli wszystkie SqlCommandi SqlReader, DataTable itp... bo to jest nie na czasie, nie trendy i cool. Co prawda praktycznie nikt nie wysilił się żeby to udowodnić.
Dla mnie pisanie zapytania ręcznie daje większe możliwości. Pamiętam jak kiedyś w ramach walki z nudą chciałem przerobić zapytanie SQL na linq i nie udało mi się. Co prawda nie zagłębiałem się zbytnio ale trochę czasu na to poświęciłem.... Bezskutecznie Dla ciekawskich zapytanie SQL:
WITH TAB_OUP_HIERARCHY(OUP_ID,OUP_NAD_ID,LEVEL,OUP_ORDER) AS
(SELECT TAB_OUP.OUP_ID,TAB_OUP.OUP_NAD_ID,0 AS LEVEL,CONVERT([varchar](MAX),TAB_OUP.OUP_KOD) AS OUP_ORDER
FROM TAB_OUP WHERE OUP_NAD_ID = N'4269bf6f-f167-43c2-b8cb-0b82354634e4'
UNION ALL
SELECT TAB_OUP.OUP_ID,TAB_OUP.OUP_NAD_ID ,TAB_OUP_HIERARCHY.LEVEL+1 AS LEVEL,TAB_OUP_HIERARCHY.OUP_ORDER + CONVERT([varchar](MAX),TAB_OUP.OUP_KOD) AS OUP_ORDER
FROM TAB_OUP INNER JOIN TAB_OUP_HIERARCHY ON TAB_OUP_HIERARCHY.OUP_ID = TAB_OUP.OUP_NAD_ID)
SELECT TAB_OUP.* FROM TAB_OUP INNER JOIN TAB_OUP_HIERARCHY ON TAB_OUP_HIERARCHY.OUP_ID = TAB_OUP.OUP_ID
ORDER BY TAB_OUP_HIERARCHY.OUP_ORDER
Tyle że aplikacje biznesowe składają się z dwóch rodzajów operacji na bazie:
- odczytów/zapisów z/do pojedynczej tabeli, i to jest właśnie naturalne miejsce do którego należy używać ORM, a ręczne klepanie sql kompletnie mija się z celem
- złożonych zapytań, tutaj jest wiele opcji:
- albo używa się widoków na bazie i ORM z nich korzysta jak chociażby w ef db first
- albo używa się micro-orm np Dapper gdzie można pisać sql
- nowsze wersja ef też umożliwiają pisanie zapytań sql i mapowanie ich na jakieś obiekty (poza ef core który jeszcze się tego nie doczekał z tego co się orientuje)
- a robienie joinów w linqu to jest głownie dla masochistów :D
Prędkość micro-orm jest porównywalna do czystego ado.net, również pisze się zapytania w sql, natomiast sobie porównaj ilość kodu którą musisz naklepać by przesłać parametry czy później odczytać dane za pomocą ado.net w porównaniu z Dapperem.
Kompletnie nie ma sensu w dzisiejszych czasach używać czystego ado.net, datasety i datatable może by się jeszcze jakoś obroniły, ale nie czyste ado.net
To nie chodzi o to, że pisanie SQL z palca nie jest trendy, tylko o to, że w przypadku trywialnych operacji CUD oraz znakomitej większości zapytań w typowych aplikacjach, robienie tego jest tylko stratą czasu. Podobnie jak ręczne tworzenie struktury bazy i podobnie jak ręczne mapowanie relacji na klasy (o ile są klasy, a nie wszędzie kod proceduralny w oparciu o DataTable) oraz samodzielne implementowanie unit of work.
Trzeba po prostu wiedzieć, kiedy użyć którego narzędzia, a nie uprzeć się na jedno i wbijać śruby piłą.
neves napisał(a):
Kompletnie nie ma sensu w dzisiejszych czasach używać czystego ado.net, datasety i datatable może by się jeszcze jakoś obroniły, ale nie czyste ado.net
Nie no, to DataSety i DataTable właśnie nie mają sensu, bo jeśli już mamy coś generować, to niech to będą cywilizowane klasy. A gołe ADO.NET do wykonywania np. operacji wsadowych albo pojedynczych zapytań z pominięciem ORM (np. w ramach jakichś poprawek wydajnościowych) ma jeszcze jakiś sens.