@neves: A czy to ma znaczenie w jakim języku? SQL, Linq, Criteria... Tak czy siak masz kod warstwy DAL osadzony w innej warstwie (widok, logika...) i to chyba kasuje abstrakcyjność takiego rozwiązania. A QueryObject też nie powinien raczej być stosowany warstwach innych niż DAL (okna w WinForms czy kontrolery w web). To tylko taki interpreter SQL <=> objects, żeby w czystym SQL-u nie grzebać bez potrzeby co wynika z podanego przez Cienie linka.
Ma ogromne znaczenie ! Różne bazy danych używają różnych dialektów sql, zresztą entity framework może operować na dowolnym źródle danych dla którego dostarczysz mu providera (chociażby bazy w pamieci).
E tam. Providery do EF też mogą być delikatnie specyficzne. Czasem np. migracje działają a czasem nie działają. Mam u siebie zapytanie Linq, które się nie wykona na niczym oprócz SQL Servera (przynajmniej w momencie pisania tamtego kodu). I prawdę mówiąc zwisa mi to, bo prawdopodobieństwo zmiany silnika bazy wynosi 0,01. Ale, oczywiście, EF zapewnia solidne, realne odcięcie od specyfiki SQL-a. Z tym nie dyskutuję.
A tak naprawdę to chyba się nie zrozumieliśmy. SQL czy jego brak to nie jest abstrakcja warstw. Abstrakcja jest wtedy kiedy widok (okno, controller, endpoint) nie ma pojęcia jak w ogóle jest realizowany dostęp do DB, a właściwie do danych bo może nawet nie być żadnej bazy. Łyżka nie istnieje.
W warstwie abstrakcyjnej możesz mieć SQL, EF, NHibernate, WCF, webapi, XML-RPC i cokolwiek innego co potrafi wysłać gdzieś lub odebrać dane (nawet jakieś wynalazki w stylu DCOM, Pipes, DDE, PPS). To jest abstrakcja a nie, ze EF odcina od SQL-a. Masz interfejs z jakiegoś repository czy serwisu i masz 5, 8, 12 metod jakoś operujących na modelach.
Więc w teorii możesz podmienić żródło danych i dzięki warstwie DAL stworzonej za pomocą EF nie musisz nic zmieniać w warstwach które od niej zależą. Bo te warstwy zależne od DAL używają abstrakcyjnego języka który jest interpretowany na SQL specyficzny dla relacyjnej bazy danych, ba to nawet nie musi być SQL.
A jak zechcę zmienić źródło danych z bazy na WCF? Mam pisać provider do WCF-a? A REST? Co z ta abstrakcją? A takie rzeczy się zdarzają. Mój bieżący case. W moim programie była baza klientów w mojej bazie danych (dostęp przez serwis z EF) a u jednego z klientów baza klientów jest w Comarch XL. EF mi raczej nie wyciągnie danych z XL-a przez jego API. Gdybym miał EF w oknach to musiałbym przepisać wszystkie okna. Jak mam dostęp do danych w serwisie wystawiającym jakiś interfejs to piszę kolejny serwis implementujący ten interfejs gadający z XL-em. Zmieniam jedną, konkretną, możliwą do przetestowania i dość prostą klasę. Podobnie z produktami, opcjami produktów, fakturami... To oczywiście specyficzny przykład ale pokazuje co to jest abstrakcja.
Czyli mamy warstwę -> bo dzięku EF nie uzywamy niczego co jest pod spodem niej, czyli specyficznych driverów do naszego wybranego źródla danych
Raczej nie. Mamy uogólniony dostęp obiektowy zamiast SQL-owego. W dawnych czasach, jak nie było ORMów to i tak z 95% (a może nawet więcej) kodu SQL-wego w typowych aplikacjach była standardowa.
Bo niby czym się różni
DbContext.Zamówienia.Where(x=>x.... == ...).GroupBy(...)
od
select * from zamówienia where ... = ... group by... ?
Taki kod przejdzie na każdej bazie.
Czyli mamy abstrakcję -> bo zapytania tworzymy w uogólnionym języku który jest tłumaczony na specyficzny język źródla danych
To nie jest abstrakcyjna warstwa dostępu do danych tylko "zobiektowanie" operacji bazodanowych. W warstwie DAL możesz mieć EF albo czystego SQL-a albo cokolwiek innego. DAL powinna enkapsulować całą logikę dotyczącą operacji na źródłach danych (cokolwiek jest źródłem, nie tylko baza danych).
Jak dalej zauważyleś w wielu przypadkach bazowanie na samym EF nie jest dobrym pomysłem, ale to nie zmiena faktu że sam w sobie EF jest warstwą abstrakcji źródła danych i nie może tego skasować to że użycie jego samego jako DAL moze się skończyć katastrofą dla projektu :).
No właśnie zmienia. Chyba inaczej rozumiemy abstrakcję źródła danych bo mi wychodzi, że w Twojej definicji to jest abstrakcja bazy danych a nie źródła, które nie musi być nawet bazą danych.
Nawet jeśli EF zwraca nie wprost modele z tabel db tylko tworzy jakieś nowe "viewmodele" to i tak masz ten kod z jednej warstwy (DAL) w innej warstwie co eliminuje enkapsulację źródła danych.
I ponownie. W super prostych CRUDach może mieć sens ale jeśli w ogóle mówimy o warstwach to niech to będą niezależne warstwy.