Linq將何去何從

微軟的EntityFramework隨著.net Framework 3.5sp1一起發布了，這個Entity Framework 雖然與linq to sql同為orm架構，但絕非linq to sql的升級。
EntityFramework的風格更像ado.net的標準寫法，查詢語句並非linq風格，而是普通的字串。這好像與 Hibernate的HQL又走到了一起。
在我看來，EntityFramework 的推出基本上就意味著linq to sql退出曆史舞台。而Linq 就如高樓還未建成，就缺了最主要的那根頂樑柱，難有完工那一天了。
Linq是.net Framework 3.5力推的編程特性，號稱將改變程式員的編程習慣的東西，在之前推出的一系列如擴充方法，var類型，都是為linq打基礎。但是現在不得不說，Linq還沒來得及風光，好日子恐怕就要過去了。
Entity Framework為何不再linq to sql基礎上發展，而採用ado.net的傳統風格？我想主要還是Linq自身的一些缺陷。
首先linq的風格雖然華麗，但是寫法和其他代碼格格不入，影響整體布局。
其次linq的寫法不能支援動態附加的查詢條件（要加條件只能直接使用Where()這樣的擴充方法）。linq的查詢語句，翻譯成擴充方法，就是方法鏈的風格，而你無法在不使方法鏈中斷的情況下，動態指定到底執行鏈中的哪些方法。而如果採用字串作為查詢語句，那麼就靈活多了——你可以隨意的拼湊字串，直至最終得到你所需的。
最後一個問題，也是linq最大的硬傷：linq查詢語句本身就是程式執行的一部分。就因為這，使得在程式運行時還沒來得及對整條語句進行分析，就已經不得不開始執行一些子句了。select子句必須寫在最後就是這個問題的最直接證明。當然這個問題的影響遠遠不止select子句的位置那麼簡單。因為運行時無法對linq語句有個整體的分析，因此這個工作不得不被放到了編譯期，但是編譯期所能獲得的資訊與運行時不可同日而語，光是最重要的一點：實際資料庫的情況，在編譯時間，編譯器對它就一無所知。
就因為這個原因，很多複雜的查詢功能，linq不是實現不了，就是實現起來很複雜，並且大部分情況都得在linq語句的這裡那裡嵌滿擴充方法，反而不優雅。又比如更新，就會先查詢再更新；刪除會一條條刪除，不會直接大量刪除。

再拿最簡單的外串連抓取(orm架構並不常需要顯式作串連查詢，但由於lazy-loading產生的n+1問題，外串連抓取是一種提高效能的方案)來說，在linq中就必須用 join ...into形式的句式將結果選入一個臨時變數，然後再另開一個from子句將臨時變數中結果選出，如

var res = from p in ctx.Products
                       join c in ctx.Categories
                       on p.CategoryID equals c.CategoryID
                       into pro
                       from x in pro.DefaultIfEmpty()
                       select p.ProductName;

 

複雜程度甚至還遠遠超過sql的外串連查詢。

而如果採用字串作為查詢語句，那麼在運行時對查詢語句進行解析就變得輕而易舉，查詢語句能力理論上也就可以和sql做得一樣強大。

因此我認為，最後所提的這個問題就是導致Entity Framework捨棄linq風格，迴歸字串的主要原因。

從概念上講，Entity Framework雖然後於linq to sql出來，但是linq to sql更有未來感，很前衛很激進。但微軟走這條路顯然不順利，無論前面為它做了多少準備，多少鋪墊，到最後發現還是走不下去。而Entity Framework則是一種理性的迴歸，更務實更保守，它的這條路，Hibernate早在幾年前已經走通了，所以技術上不會有任何問題。