为什么LINQ设计人员不坚持使用今天编写sql的方式？

例如，为什么要在LINQ中这样做

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

他们本可以这样做的时候：

var products = select p.Name from Products p;

第二个在linq中提供了一些限制吗？

---

也许上面的例子太简单了，无法真正理解为什么linq是以一种顺序编写的，而sql是以另一种顺序编写的。

因为为了让Visual Studio中的Intellisense使用linq，它需要先了解表，以便编辑器可以向程序员提供可供选择的列列表。如果您使用SQL方式，首先选择列，编辑器就无法真正帮助您，因为它不知道要查看哪些表。

，因为LINQ不是SQL。当您使用System.LINQ命名空间时，LINQ由IEnumerable上的许多链式扩展方法组成。类似SQL的语法只是一个编译器技巧，可以在这些查询方法的链上启用一些语法糖，这样您就可以在.NET语言中使用看起来有点像SQL的查询。LINQ基本上与SQL本身无关…

人们常说原因是Intellisense。因为如果你开始写作

select p.

编译器无法告诉您要显示哪些属性

但是如果你从

from person p select p.

它知道如何查找person对象的属性

嗯

---

alex

Intellisense经常被引用为一个原因，但我认为更好的解释是选择逻辑发生在查询编写过程的末尾。首先设置数据源，然后进行筛选和分组，然后一旦一切就绪，就可以指定要获取的内容。

尽管其他人正确地指出，提供智能感知是影响Ander决策的部分原因，需要考虑的另一点是LINQ不仅仅用于SQL。由于LINQ是一种更具包容性的技术，所以它从来没有被限制为仅以SQL的方式工作。

扩展了peSHIr的说法

LINQ基于lambda演算的数学原理

---

.

撇开IntelliSense、查询表达式扩展等都是合理的理由不谈，我实际上相信LINQ方式更有意义

从数据源开始。您应用过滤器、排序等，然后以投影结束。换句话说，查询是按照操作的逻辑顺序编写的

---

换一种说法：SQL设计者究竟为什么选择这样对SQL查询排序？

事实上，LINQ的语法更接近于基于XQuery而非SQL，XQuery也是这样做的

主要原因已经给出：在C、VB.NET和大多数编程语言中，作用域从上到下、从左到右流动，这与我们通常阅读的方式相同。SQL的编写方式是范围跳跃：标识符已经在查询的SELECT部分中使用，但它只是在查询的FROM部分的后面引入。这就是为什么XQuery的设计者决定改变它，LINQ也跟着改变

---

它也更符合心智模型：您有来自的数据源列表，然后过滤出您感兴趣的数据，然后按顺序对数据进行排序，最后将其投影到不同的表示形式中，选择或按分区结果组。之后，您可以将结果注入到下一个查询中。

我记得Anders在第9频道的一次采访中提到了这一点。LINQ还受到其他查询语言的影响，比如XQuery，而不仅仅是SQL。事实上，这很明显。好的，我明白你的意思了。现在它更有意义了。似乎当他们谈到LINQ时，他们试图用在代码端使用LINQ查询来代替在数据库端编写sql查询。最好将LINQ看作是在代码中支持查询，而不是在代码中支持sql。绝大多数SQL都不受支持，也不应该受支持。很多第一次看到LINQ的人都觉得很酷！我的代码中包含SQL，但从未真正得到LINQ是什么。基本上，LINQ是.NET当前函数式编程范式转变的开始。事实上，让我们开始使用它是相当聪明的，因为查询、思考SQL、让程序员准备好进行函数式编程而他们甚至没有注意到-另外，重要的是要认识到LINQ不需要扩展方法，也不受IEnumerable的限制。从根本上说，查询表达式只是语法糖，编译器将其转换为以正常方式解析的方法调用。查询运算符最常见的来源是System.Linq中的扩展方法，但它们不是唯一的。Linq与IEnumerable或扩展方法无关，实际上它所需要的只是一些名为Select、Where等的方法可以在您使用的对象上调用。Linq是类似查询的表达式到方法调用的一元翻译，就是这样。@Jon:因为所有程序员都会思考 SQL是程序化的！