java linq_LINQ和Java

java linq

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

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

声明式编程意味着程序员不会明确声明其算法。 相反，他们描述了他们想要获得的结果，从而将算法计算留给了他们的实现系统。 一些数据库已经非常善于解释大型SQL语句，并基于语言语法和元数据应用了SQL语言转换规则。 有趣的一读是汤姆·凯特 （ Tom Kyte）的元数据问题 ，这暗示了Oracle基于成本的优化工具所做的巨大努力。 对于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.Products
    where !prod.Discontinued
    select prod)
    .Count();

Console.WriteLine(notDiscontinuedCount);

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

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

var prodCountQuery =
    from prod in db.Products
    group prod by prod.CategoryID into grouping
    where grouping.Count() >= 10
    select 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.Products
    group prod by prod.CategoryID into grouping
    select 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可能是一个不好的选择，原因有两个：

1. 某些SQL机制无法用LINQ表达。 与JPA一样，您可能需要使用普通SQL。
2. 某些LINQ机制无法用SQL表示。 与JPA一样，您可能会遇到严重的性能问题，因此将再次诉诸于纯SQL。

选择LINQ或其“ Java实现”时，请当心以上内容！ 使用SQL（即JDBC， jOOQ或MyBatis ）进行数据提取，并使用Java API（例如Java 8的Stream API）进行内存中后处理可能会更好。

类似于LINQ的库在Java，Scala中建模SQL

• jOOQ： http ： //www.jooq.org
• Sqltyped： https ： //github.com/jonifreeman/sqltyped

类似于LINQ的库在Java，Scala中抽象化SQL语法和数据存储

• Quaere： http ：//quaere.codehaus.org
• JaQu： http ：//www.h2database.com/html/jaqu.html
• Linq4j： https ： //github.com/julianhyde/linq4j
• 光滑： http ： //slick.typesafe.com/

参考：来自JACG ，SQL和AND JOOQ博客的JCG合作伙伴 Lukas Eder的LINQ和Java 。

翻译自: https://www.javacodegeeks.com/2013/07/linq-and-java.html

java linq