Java 8 是否還需要 LINQ？還是已經比 LINQ 更好？

　　LINQ一直是.net程式系統中的一個非常棒的東東. Visual Studio 2008 已經引入了lambda 表示式和monads, 而同一時間Java6版本還在討論要不要去掉泛型資料型別. 這一成果要歸功於荷蘭電腦科學家Erik Meijer, 他已經全停止掉別的專案.

　　Erik Meijer. 攝影:Ade Oshineye. 授權給CC-BY-SA

　　Java的現狀?

　　即將要釋出的Java8和JSR-355,我們還需要LINQ?在過去的十幾年中人們一直在嘗試用LINQ給Java帶來效能的改良。當時,Quaere和Lambdaj似乎在研究一種很有前途的庫（非語言級別）. 事實上,StackOverflow上有很多Java的使用者提出的有沒有與LINQ等價的Java做法(到現在依然) :

• LINQ的Java實現?
• LINQ的Java工具
• Java中有跟LINQ類似的東西麼?
• Java等效LINQ和實體框架是什麼?

　　有趣的是, "LINQ"已經發展到EL 3.0版本了!

　　我們真的需要LINQ麼?

　　LINQ的高階特性存在重大缺陷, 從我們角度看來, 將會導致 "next big impedance mismatch". LINQ來源於SQL,這不是一件完美的事情. LINQ流行的LINQ-to-Objects,在.NET下是一種很好的查詢方式.Haskell或Scala的成功已表明,真正的函數語言程式設計可以忽略SELECT,WHERE,GROUP BY, 或者HAVING等來進行集合查詢。他們使用"fold", "map", "flatMap", "reduce",來獲得更高的效能.另一方面LINQ用 "skip", "take"使用混合式GROUP BY(不是OFFSET和FETCH).

　　事實上, 沒有一種函式式查詢方法可以超越那老舊但好用的SQL外部連結, 分組設定,或 框架視窗功能. 這些結構僅僅是一個SQL開發人員希望看到的結果的宣告。他們不是自足的功能，這實際上包含在任何給定的情況下被執行的邏輯。此外，視窗功能，可以只用在SELECT和ORDER BY子句，這是一種明顯宣告方式，但是如果你沒有SQL上下文這也是非常奇怪的。具體來說，SELECT子句中的視窗函式採用正確的資料預取影響整個執行計劃和索引的方式。

　　相反，函數語言程式設計可以在記憶體中就做到SQL的這些功能。使用SQLesque API 進行集合查詢是用函式式方式狡猾的欺騙 了"傳統"的人。這樣的實現方式是不能將集合資料與SQL表查詢的資料合併在一起的，也不會產生預期的SQL查詢結果。

　　我該如何做?

　　相當簡單，你如果使用SQL，你就有兩個基本選擇:

• 自上而下,專注你的Java模型. 使用Hibernate / JPA查詢並且使用Java8 Streams API 轉化Hibernate的查詢結果.
• 自下而上,專注你的SQL關係模型. 繼續使用JDBC或者jOOQ, 使用Java8 Streams API 轉化的查詢結果.

　詳情猛擊這裡: http://www.hibernate-alternative.com

　　（譯註:這老外不就是說Java8提供了一種介面麼,這麼費勁）

　　不能回頭.擁抱未來!

　　雖然 .NET "領先" Java了一些，但這並不是LINQ的問題. 這主要是由於引入了lambda表示式並且支援lambdas的很多APIs. LINQ僅僅只是如何構建這樣API的例子.

　　但我更加興奮的期望Java 8中的 new Streams API, 以及它給Java生態系統帶來的函數語言程式設計. 這是一個由Informatech illustrates寫的很棒的一篇博文:如何將常見的LINQ表示式轉換為Java 8 Streams API表示式.

　　所以，不能回頭.你可以不用再對.NET開發者眼饞嫉妒. 因為Java 8,我們已經不需要LINQ或者其他API模仿LINQ的"unified querying", 有一個更好的稱呼，像"query target impedance mismatch".我們需要真正的SQL關係型資料庫查詢,我們需要Java 8 Streams API函數語言程式設計查詢記憶體集合資料. 給力 Java 8!

　　原文地址：does-java-8-still-need-linq-or-is-it-better-than-linq/