Linq To Sql是Microsoft開發(fā)的針對解決data!=object問題的新技術(shù)。在筆者的一系列的文章中,對它已經(jīng)做了大量的介紹?,F(xiàn)在,筆者將從經(jīng)驗的角度,談?wù)勊膬?yōu)劣。
1、Linq To Sql的優(yōu)點
在Linq To Sql推出之前,我們只是把sql語句形成一個string,然后,通過ado.net傳給sql server,返回結(jié)果集.這里的缺陷就是,如果你sql語句寫的有問題,只有到運行時才知道.而且并不所有的人都懂?dāng)?shù)據(jù)庫的。Linq To SQl 在一切圍繞數(shù)據(jù)的項目內(nèi)都可以使用。特別是在項目中缺少sql server方面的專家時,Linq To SQl的強大的功能可以幫我們快速的完成項目。Linq To SQl的推出,是讓大家從煩瑣的技術(shù)細(xì)節(jié)中解脫出來,更加關(guān)注項目的邏輯。Linq To Sql的出現(xiàn),大大降低了數(shù)據(jù)庫應(yīng)用程序開發(fā)的門楷,它實質(zhì)是事先為你構(gòu)架了數(shù)據(jù)訪問層,勢必將加快數(shù)據(jù)庫應(yīng)用程序的開發(fā)進(jìn)度。Linq To Sql解放了眾多程序員,讓他們的把更多的精力放到業(yè)務(wù)邏輯以及code上,而不是數(shù)據(jù)庫。對于初學(xué)者來講,Linq To Sql可以讓他們迅速進(jìn)入數(shù)據(jù)庫應(yīng)用程序開發(fā)領(lǐng)域,節(jié)約了培訓(xùn)成本。
Linq To SQl 的實現(xiàn),是在ado.net和c#2.0的基礎(chǔ)上的。它通過自動翻譯sql語句,并把結(jié)果集創(chuàng)建成對象并返回。這里我們可以看出,發(fā)送到Sql Server端的sql語句是Linq To Sql自動生成的。這對不懂sql的人來說,無疑是個福音。第二,Linq To Sql語句是在編譯期間就做檢查的。而不是運行時檢查。這樣,那里出了問題,可以及時更改,而不是到了運行時才發(fā)現(xiàn)問題。第三,Linq To Sql是針對對象操作的,更符合今天的oo呼聲。
在Linq To SQl 之前,在java領(lǐng)域有Hibernate,在net領(lǐng)域有NHibernate技術(shù),來實現(xiàn)object/relational 持久和查詢服務(wù)。那和NHibernate比起來,它又有那些優(yōu)勢呢.第一,影射代碼自動生成。VS2008提供了SqlMetal和OR Designer兩個工具來完成此步驟。而在NHibernate中,你不得不自己手工寫。第二,影射代碼有更多的選擇.NHibernate只能把數(shù)據(jù)庫的信息配置在一個xml中,而Linq To Sql有兩種方式,一個是放到xml中,我們稱為Externl Mapping, 再一種就是以Attribute的形式,存在于各個property中。當(dāng)然,筆者本人并沒有使用過NHibernate,只是從資料上得到這些消息,所以無法給出更多的比較。
2、Linq To Sql的缺點
很久前,有個網(wǎng)友問到這么一個問題。他在界面上有個DataView,里面綁定了一些Column,然后他勾選那一列就按某列排序。其傳回的參數(shù)是列的名字。然后問我該怎么用Dlinq 來實現(xiàn)。
在以前拼接Sql語句的年代,這個很簡單,一個" order by " + string,想按什么排就按什么來排。而現(xiàn)在dlinq是用是一個對象的屬性,已經(jīng)不可能拼接了。我當(dāng)時給他的答案是這樣的。
以下是引用片段: private void Methods(string orderId) { var q = db.Customers.Select(c=>c); switch(orderId) { case "ID": q = q.OrderBy(c=>c.ID); break; case "Name": q = q.OrderBy(c=>c.Name); break; default: break; } var result = q.ToList(); } |
我那時也沒有想出一個更好的方案來。而后告訴他去查下Compiled Query,說不定可以找到更方便的。后來我才在這個例子中,看到更方便的。
以下是引用片段: var query = db.Customers.Where("City == @0 and Orders.Count >= @1", "London", 10). OrderBy("CompanyName"). Select("New(CompanyName as Name, Phone)"); |
在這里OrderBy直接接收的就是列的名字。再仔細(xì)一看,好像Where里是Linq的語句哎,那OrderBy也該是linq語句。后來,我把CompanyName換成小寫的,一跑過了。莫非真的是列的名字?出個難題吧。找了一個列名,是帶空格的,重新來建這個工程.一跑,錯了!把列名用中國擴(kuò)號擴(kuò)起來了,也是錯了???,只是動態(tài)構(gòu)造Expression Tree而已,永遠(yuǎn)都不能直接接收列的名字。這個例子看著是很簡單,可不知道你有沒有注意到它有一個80多k的Dynamic.cs文件。更有意思的事情是,它的名稱空間是System.Linq.Dynamic.看樣子,ms本來是打算把它加在.net3.5中嗎.不曉得為什么放到了例子中了。這個名稱空間下,其主要內(nèi)容就是動態(tài)構(gòu)造Expression Tree. 和Linq To Sql進(jìn)階系列(七)動態(tài)查詢 一文中的方法類似。只是,它還包含了解析字符串部分.
從上面那個例子中,可以看出,Linq To Sql在這種動態(tài)構(gòu)造語句時,比拼接sql麻煩很多。在Linq To Sql進(jìn)階系列(七)動態(tài)查詢 一文中,筆者極力推薦使用object的查詢。這符合Linq To Sql的設(shè)計原則。因為,它主要是為了解決data!=objects 的問題而產(chǎn)生的.它所有的操作均針對object,那就讓我們使用object的查詢吧.
當(dāng)然,依然會有人習(xí)慣拼接字符串.我并不認(rèn)為這是個壞毛病。只是有點不符合oo思想而已。事實上,在Linq To Sql中,你依然可以使用拼接字符串的形式,而不使用它提供的Query Expression. 它提供了這么兩個接口,一個是,db.ExecuteQuery
看下面的例子:
以下是引用片段: var products = db.ExecuteQuery( "SELECT [Product List].ProductID, [Product List].ProductName " + "FROM Products AS [Product List] " + "WHERE [Product List].Discontinued = 0 " + "ORDER BY [Product List].ProductName;" ).ToList(); |
它返回的就是product的集合。而不是什么dataset和datatable之類的。這里,你可以大膽的使用該函數(shù)繼續(xù)拼接你的sql吧,再看下面這個:
以下是引用片段: db.ExecuteCommand("UPDATE Products SET UnitPrice = UnitPrice + 1.00"); |
它在做批處理的時候,你想不用它,都不行.當(dāng)然,你如果覺得性能不是問題的話,那就用submitchange方法來做更新好了。簡單明了的說,Linq To Sql在批處理更新的時候,SubmitChange只會一個個的更新。浪費時間資源.而這個接口,恰好滿足了批處理更新或刪除的問題。從這兩個例子,我們可以看出。沒有任何方案是萬能的。各有各的優(yōu)點。
3、Linq To Sql的性能
Linq 的性能已經(jīng)被好多人提及.Linq To Object 的性能大家討論的比較多些.它確實比自己實現(xiàn)的查找要慢.但是當(dāng)數(shù)據(jù)量特別大時,更多是時間是花在分配虛擬內(nèi)存上了,那么他們的差別就不是那么明顯了。Linq To Sql是又如何提升性能的?第一,采用延遲加載(deferred loading)技術(shù)。語句是聲明了,但是并不立即執(zhí)行,而是在真正需要的時候才執(zhí)行。第二,采用緩存技術(shù)。已經(jīng)取到內(nèi)存的數(shù)據(jù),再依次提取時,會先從緩存中返回,而不是再次訪問數(shù)據(jù)庫。當(dāng)然,筆者建議,不要對象的時候,沒有必要使用Linq To Sql.比如,只是填充DataView或DataGrid時,返回dataset或datatable要比用Linq To Sql實現(xiàn)的快很多。
結(jié)論:各種技術(shù)都有其自身的優(yōu)點和缺點。使用什么樣的技術(shù),完全在于項目對性能和開發(fā)進(jìn)度的要求,以及程序員自身的愛好有關(guān)。揚長避短,才是正道。