Dlaczego projektanci LINQ nie trzymali się przy użyciu sposobu, w jaki sql jest dzisiaj zapisywany?

Question

Na przykład, dlaczego robisz to w LINQ

var products = from p in Products 
       select p.Name; 

kiedy mogliby zrobić to:

var products = select p.Name from Products p; 

robi drugą ofertę pewne ograniczenia w LINQ? Być może powyższe przykłady są zbyt proste, aby zobaczyć, dlaczego linq jest napisane w jednym zamówieniu, a sql jest napisane w innym.

Answer 1

Ponieważ LINQ nie jest SQL. LINQ składa się z wielu połączonych metod rozszerzenia na IEnumerable<T> (w przypadku korzystania z przestrzeni nazw System.Linq). Składnia podobna do SQL jest po prostu sztuczką kompilatora, aby włączyć trochę cukru syntaktycznego w łańcuchach takich metod zapytań, więc wydaje się, że możesz używać zapytań wyglądających trochę jak SQL w językach .NET. LINQ zasadniczo nie ma nic wspólnego z SQL per se ...

Answer 2

Ponieważ aby IntelliSense w Visual Studio pracował z LINQ, musi najpierw znać tabele, aby edytor mógł zaoferować programistom listę kolumn do wyboru. Jeśli zrobisz to w sposób SQL i najpierw wybierzesz kolumny, edytor nie może ci naprawdę pomóc, ponieważ nie wie, na których tabelach patrzeć.

Answer 3

Często cytuje się, że powodem jest Intellisense. Ponieważ jeśli zaczniesz pisać, kompilator nie będzie mógł powiedzieć, jakie właściwości mają ci pokazywać.

ale jeśli zaczniesz z

from person p select p. 

wie patrzeć na właściwości obiektu osobą.

HTH alex

Answer 4

Intellisense jest często cytowany jako powód, ale myślę, że lepiej jest wyjaśnienie, że Wybierz logicznie dzieje pod koniec procesu pisania zapytań. Najpierw konfigurujesz źródła danych, następnie filtrujesz i grupujesz, a kiedy już wszystko masz na miejscu, określasz, co chcesz wydostać.

Answer 5

Podczas gdy inni poprawnie stwierdzili, że dostarczenie intellisense było jedną z przyczyn, które wpłynęły na decyzję Ander, coś jeszcze, co należy wziąć pod uwagę, to to, że LINQ nie jest przeznaczony tylko do użycia z SQL. Ponieważ jest to o wiele bardziej wszechstronna technologia, LINQ nigdy nie było przeznaczone do tego, aby działać tak, jak robi to SQL.

Answer 6

Poszerzenie tego, co powiedział PeSHIr.

LINQ opiera się na matematycznych zasadach rachunku lambda.

You need to study/understand how LINQ query operators map to actual methods.

Answer 7

Pomijając IntelliSense, rozszerzanie wyrażenia zapytań itp. (Które są uzasadnione), uważam, że sposób LINQ ma dużo więcej sensu.

You Uruchomienie ze źródłem danych. Stosujesz filtry, zamawiasz itp. Kończysz projekcją. Innymi słowy, zapytanie jest pisane w logicznej kolejności operacji.

Mówiąc inaczej: dlaczego, na litość, projektanci SQL zdecydowali się na takie zapytania SQL?

Answer 8

W rzeczywistości składnia LINQ jest ściślej oparta na XQuery niż na SQL, a XQuery robi to w ten sposób.

Główne powody zostały już podane: w języku C#, VB.NET i rzeczywiście w większości języków programowania, zakres przepływa od góry do dołu i od lewej do prawej, tak jak zwykle czytamy. Sposób zapisywania SQL, zakres przeskakuje: identyfikator jest już użyty w części zapytania jako w części dotyczącej zapytania, ale zostanie wprowadzony dopiero później, w części zapytania dotyczącej . Właśnie dlatego projektanci XQuery postanowili go odwrócić, a LINQ właśnie podąża.

pasuje również model mentalny lepsze: masz listę źródeł danych (FROM), a następnie odfiltrować dane jesteś zainteresowany (WHERE), a następnie posortować te dane (ORDERBY) i wreszcie trzeba albo projekt do innej reprezentacji (SELECT) lub podziel wyniki (GROUP BY). Następnie możesz wprowadzić wyniki do następnego zapytania (INTO).