LINQ的優點
LINQ的主要優點體現在它是一種標準，不但可以在一個關系數據庫中進行查詢操作，而且可以在文本文件、XML文件以及使用同一語法的數據源中查詢數據。此外，任何.NET兼容的語言，比如C#，VB.NET等都可實現LINQ標準。
查看與體會LINQ
以下代碼段(在C#中)使用Northwind數據庫演示了一個簡單的LINQ代碼塊。為了能全面看到LINQ的工作過程，我們以一段簡單C#3.0程序為開始，這段程序使用標準查詢操作符處理一個數組的內容。
using System; using System.Query; using System.Collections.Generic; class app { static void Main() { string[] names = { "Alpha", "Brian", "Connie", "David", "Frank", "George", "Harry", "Inigo" }; IEnumerable expr = from s in names where s.Length == 5 orderby s select s.ToUpper(); foreach (string item in expr) Console.WriteLine(item); } }
ALPHA BRIAN DAVID FRANK HARRY INIGO
我對前端與后端的觀點
我將論述一下客戶端服務配置前端與后端的關系。后端為處于服務器的數據庫本身，而前端為客戶應用程序，即包括任何以常用開發語言編寫的程序(比如Visual Basic，C++以及PHP)。當提及前端時，我們通常也包括微軟的Access，Excel以及Word等程序。
在一個少于100臺電腦的小型組織中，我以上提到的觀點(即LINQ程序放在臺端)看似很理論性，但后端的LINQ相比于放置在前端則更具有邏輯性。比如在一個程序段中，建立一個記錄集，使用一個或多個參數限定選擇規則，然后以一列或多列排列它們。如果我將程序的邏輯判斷部分放置在任一給定的前端中，那么在下幾周或幾個月內，我必須在新增加的前端程序中復制這一LINQ程序段。盡管我們可以認為這些邏輯判斷是獨立存在的語言，但實際操作起來卻并非如此。
開發過程通常從典型的客戶-服務器過渡到三層架構(DLL-hell，SOAP等)的各種形式。在這些架構中，前端程序告訴一個中間架構，這一中間架構包含很多邏輯，并以前端關鍵內容作為地址。中間架構的作用是實現數據庫的匹配。這種交流過程因使用的前端語言和中間架構的不同而不同，中間架構可以與數據庫服務器相互通訊，前端程序只負責與中間架構的聯系。我的觀點是，前端程序負責的部分要盡量減少。你可使用一個中間架構，然后將所有邏輯轉移到中間架構，并把所有設計部分和邏輯判斷轉移到后端程序。
我的觀點可能有點樂觀
我始終遵循這樣一條原則：后端可完成的事情，它就應該完成�；谶@一原則，你可以理解我不愿將數據庫邏輯判斷放置在前端的原因。
為何我對這一原則如此堅定?因為以我的經驗，很多不同的前端程序只和一個數據庫連接，這些前端程序可能是Web程序、Visual Studio程序、Delphi程序等。如果將這些代碼從后端移動到前端，你必須復制并編譯這些代碼成為每一前端程序。這對于Visual Studio.NET是有用的，但你或你的老板可能會要求使用其它編程語言?或者，如果你將邏輯判斷部分導入到其它數據庫，此時該怎么辦?
我的觀點也并非得到同行的認可。我知道有些開發者會提出，這種做法是否適合特定的動態查詢的程序。我認為，這種情況現在還沒有徹底分析清楚，但我認為在這一點上，以上的原則是不合適的。所以我們可以看看其它方法并證明它的正確：在N臺電腦中，在前端中建立一個合法的SQL語句，然后將這一語句傳遞到數據庫引擎。
無論以上的觀點是否正確，很多開發者都喜歡將SQL命令放置在前端而不是后端。這一群開發者一般都對LINQ感興趣。如果此時你也同意我的原則，在開發過程中可能會碰到各種困惑。
現在定論尚早
現在定論LINQ是否成為未來數據庫發展的趨勢還為時尚早。LINQ還需要數據庫和應用程序開發的進一步考驗。我確實認為LINQ的多數據源功能非常棒，但正如我開始所提到的，我覺得將代碼從后端轉移到前端是一個錯誤。
只有時間能夠說明一切。盡管當LINQ的所有優點被得以證明時，我還是堅持我的原則：后端可完成的事情，它就應該完成。
1
文章來源于領測軟件測試網 http://www.kjueaiud.com/
