长期以来, LINQ是.NET软件工程生态系统中发生的最好的事情之一。 通过在Visual Studio 2008中引入lambda表达式和monads ,它使C#语言比Java(当时的版本6)更先进,并且仍在讨论泛型类型擦除的优缺点。 这项成就主要归功于荷兰计算机科学家兼染料专家Erik Meijer并获得其认可,他现在正从事其他项目 。
Erik Meijer,Tye染料专家。 Ade Oshineye摄 。 根据CC-BY-SA许可
Java现在在哪里?
随着即将发布的Java 8和JSR-355 ,我们仍然需要LINQ吗? 自上个十年中期以来,已经进行了许多尝试来将LINQ的优点带给Java。 当时, Quaere和Lambdaj似乎是在图书馆级别(而不是语言级别)上有希望的实现。 实际上, 大量流行的Stack Overflow问题暗示了实际上有多少Java人员正在(并且仍然是!)寻找等同的东西:
- LINQ的Java等效项是什么?
- LINQ for Java工具
- 是否有类似LINQ for Java的东西?
- Linq和Entity Framework的Java等效项是什么?
有趣的是,“ LINQ”甚至已经成为EL 3.0 !
但是我们真的需要LINQ吗?
LINQ有一个主要缺陷,该缺陷被宣传为一项功能,但在我们看来,这将不可避免地导致“下一个大阻抗失配” 。 LINQ受SQL启发,这根本不是一件好事。 LINQ最流行于LINQ-to-Objects ,这是查询.NET中集合的一种好方法。 但是, Haskell或Scala的成功表明,“集合查询”的真正功能本质倾向于使用除SELECT , WHERE , GROUP BY或HAVING之外的其他术语。 他们使用的术语包括“折叠”,“地图”,“ flatMap”,“减少”等等。 另一方面,LINQ使用GROUP BY和“ skip”,“ take”(而不是OFFSET和FETCH )等术语的混合体。
实际上,除了良好的旧SQL 分区外部联接, 分组集或框架窗口函数之外,没有什么比功能真理更重要的了。 这些构造仅仅是SQL开发人员希望看到的结果的声明。 它们不是独立的函数,实际上包含要在任何给定上下文中执行的逻辑。 而且,窗口函数只能在SELECT和ORDER BY子句中使用, 这在以声明方式进行思考时很明显 ,但是如果您没有SQL上下文,这也很奇怪。 具体来说, SELECT子句中的窗口函数会影响整个执行计划,以及采用索引来预取正确数据的方式。
相反,真正的函数式编程对内存中集合的作用比SQL还要多。 使用SQLesque API进行集合查询是一个狡猾的决定 ,目的是欺骗“传统”人员采用函数式编程。 但是,使集合和SQL表查询可以混淆的希望令人失望,因为这样的构造不会产生所需的SQL执行计划 。
相反,真正的函数式编程对内存中集合的作用比SQL还要多。 使用SQLesque API进行集合查询只是错误的决定。 令人失望的是,收集和SQL表查询可能会混淆在一起,因为这样的构造将不可避免地产生可怕的SQL执行计划 。
但是,如果我
这很简单。 执行SQL时,有两个基本选择。
- “自上而下”进行操作,将大部分精力放在Java域模型上。 在这种情况下,请使用Hibernate / JPA通过Java 8 Streams API查询和转换Hibernate结果。
- “自下而上”进行操作,将大部分精力放在您的SQL /关系域模型上。 在这种情况下,请使用JDBC或jOOQ,然后再次使用Java 8 Streams API转换结果。
此处对此进行了更详细的说明: http : //www.hibernate-alternative.com
拥抱未来!
虽然.NET在Java领域已经“领先”一段时间了,但这并不是由于LINQ本身引起的。 这主要是由于引入了lambda表达式以及lambda对* ALL * API的影响。 LINQ只是如何构造此类API的一个示例,尽管LINQ赢得了大多数赞誉。
但是,我对Java 8的新Streams API以及它将如何包含Java生态系统中的某些功能编程感到更加兴奋。 Informatech在一篇非常好的博客文章中说明了常见的LINQ表达式如何转换为Java 8 Streams API表达式。
所以,不要回头。 停止羡慕.NET开发人员。 使用Java 8,我们将不需要LINQ或任何试图以“统一查询”为基础来模仿LINQ的API,这对于真正的“查询目标阻抗不匹配”来说是一个更好的称呼。 我们需要真正的SQL来进行关系数据库查询,并且需要Java 8 Streams API来进行内存中集合的功能转换。 而已。 使用Java 8!
翻译自: https://www.javacodegeeks.com/2013/11/does-java-8-still-need-linq-or-is-it-better-than-linq.html