LINQ radi sa SQL Server-om i XML-om. EF ima provajdere za sve RDBMS-ove dakle, univezalan je. S druge strane, trebalo bi da je LINQ jednostavniji za korišćenje.

Na Internetu se mogu naći blogovi o tome da MS "napušta" LINQ u korist EF-a mada, to treba uzeti sa rezervom.

Da ti odgovorim na performance deo, to zavisi od toga kakav finalni SQL generisu DLINQ/EF a to zavisi od toga sta trzis od njih da ti urade, narocito pri ispostovavanju univerzalnosti jer razliciti rdbms-ovi imju neke nijanse u tome sta je brze i efikasnije. Ne bi trebalo da ima mnogo razlike u odnosu na reader pod uslovom da readeru das isti SQL koji DLINQ/EF naprave , iz cega lako mozes izvuci zakljucak da neke stvari mozes da optimizujes i ubrzas kroz reader ako si dobar u SQL-u. Sa druge strane, DLINQ/EF ti podatke daju lepo upakovane u strong tipove.
U principu ne treba da gledas na DLINQ/EF kao na high-performance resenja, oni su tu da ti olaksaju kod, ne da ga ubrzaju. AKo ti treba neko high-performance resenje onda je pozeljno da zaboravis na application layer i sve te operacije implementiras u kontekstu servera (SP, xSP, itd).

Možeš da koristiš SP i u sprezi sa EF (kao i kod LINQ to SQL-a).

Ima mnogo diskusija na ovu temu na net-u (ne mogu sad da nađem neke PPT koje sam imao, ali potražiću).

Elem: kod LINQ to SQL-a (koji je došao prije EF-a) mapiranje klasa sa objektima iz baze jest' 1:1, i tu nema odstupanja, dok je EF - fleksibilan. EF zapravo predstavlja budućnost (nešto slično je prije EF viđeno u modelima u SQL Server BI, i pokazalo se odlično), tako da Microsoft polako napušta LINQ to SQL mehanizam.

Iako EF podržava i druge baze podataka (non-Microsoft) - ne razvija EDMX za njih, već je to prepušteno proizvođačima baza.