LINQ和Java

LINQ已经非常成功，但在.NET生态系统中也引起了争议。许多人正在Java世界中寻找可比的解决方案。为了更好地理解什么是可比的解决方案，让我们看一下LINQ解决的主要问题：

查询语言通常是具有许多关键字的声明性编程语言。它们提供的控制流元素很少，但是具有很高的描述性。最受欢迎的查询语言是SQL ，这是ISO / IEC标准化的结构化查询语言，主要用于关系数据库。

声明式编程意味着程序员不会明确声明其算法。相反，他们描述了他们想要获得的结果，从而将算法计算留给了其实施系统。一些数据库已经非常善于解释大型SQL语句，并基于语言语法和元数据应用了SQL语言转换规则。有趣的一读是汤姆·凯特（ Tom Kyte）的元数据问题，暗示了甲骨文基于成本的优化工具所付出的巨大努力。对于SQL Server，DB2和其他领先的RDBMS，可以找到类似的论文。

LINQ-to-SQL不是SQL

LINQ是一种完全不同的查询语言，它允许将声明性编程方面嵌入到.NET语言（例如C＃或ASP）中。 LINQ的一个优点是，C＃编译器可以在C＃语句中间编译类似于SQL的内容。从某种意义上说，LINQ对.NET而言，SQL对PL / SQL，pgplsql或对Java的jOOQ而言（请参阅我之前有关PL / Java的文章）。但是与嵌入实际SQL语言的PL / SQL不同， LINQ-to-SQL并非旨在在.NET中对SQL本身进行建模。它是更高级别的抽象，为尝试统一使用一种语言对各种异构数据存储进行统一查询提供了方便。这种统一将产生与ORM相似的阻抗失配，甚至可能更大。尽管相似的语言可以在某种程度上相互转换，但是对于高级SQL开发人员而言，预测甚至是非常简单的LINQ语句将生成什么实际的SQL代码也变得非常困难。

LINQ示例

当查看LINQ-to-SQL文档给出的一些示例时，这一点变得更加清楚。例如Count()聚合函数：

System.Int32 notDiscontinuedCount =(from prod in db.Productswhere !prod.Discontinuedselect prod).Count();Console.WriteLine(notDiscontinuedCount);

在上面的示例中，尚不清楚立即将.Count()函数转换为带括号的查询中的SQL count(*)聚合函数（然后为什么不将其放入投影中？），或者是否将其应用仅在执行查询后，才在应用程序内存中。如果需要将大量记录从数据库传输到内存，则后者将是禁止的。根据交易模型的不同，它们甚至需要被读取锁定！

此处给出了另一个示例，其中解释了分组：

var prodCountQuery =from prod in db.Productsgroup prod by prod.CategoryID into groupingwhere grouping.Count() >= 10select new{grouping.Key,ProductCount = grouping.Count()};

在这种情况下，LINQ对它的语言方面建模完全不同于SQL。上面的LINQ where子句显然是SQL HAVING子句。 into grouping是将元组into grouping的别名，这是一个很好的主意。但是，它不会直接映射到SQL，并且LINQ必须在内部使用它来生成类型化的输出。当然，很棒的是静态类型的投影，之后可以直接在C＃中重用！

让我们看另一个分组示例：

var priceQuery =from prod in db.Productsgroup prod by prod.CategoryID into groupingselect new{grouping.Key,TotalPrice = grouping.Sum(p => p.UnitPrice)};

在此示例中，C＃的功能方面嵌入到LINQ的Sum(p => p.UnitPrice)聚合表达式中。 TotalPrice = ...只是简单的列别名。以上让我有很多未解决的问题。在SQL查询返回部分结果集之后，如何控制哪些部分将真正转换为SQL，以及哪些部分将在我的应用程序中执行？我如何预测lambda表达式是否适合LINQ聚合函数，以及何时将导致将大量数据加载到内存中以进行内存聚合？并且：编译器会警告我，它无法弄清楚如何生成C＃/ SQL算法组合吗？还是这只会在运行时失败？

去LINQ还是不去LINQ

不要误会我的意思。每当我在LINQ手册中寻找灵感时，我都会强烈希望在项目中进行尝试。它看起来很棒，而且设计合理。关于Stack Overflow也有很多有趣的LINQ问题。我不介意在Java中使用LINQ ，但是我想提醒读者，LINQ 不是 SQL。如果您想控制SQL，则LINQ或LINQesque API可能是错误的选择，原因有两个：