日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

1、LINQ to SQL的優(yōu)點(diǎn)

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對(duì)這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡(jiǎn)單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名與空間、網(wǎng)站空間、營(yíng)銷軟件、網(wǎng)站建設(shè)、蓬安網(wǎng)站維護(hù)、網(wǎng)站推廣。

在LINQ to SQL推出之前，我們只是把SQL語句形成一個(gè)string，然后，通過ado.net傳給SQLserver，返回結(jié)果集.這里的缺陷就是，如果你SQL語句寫的有問題，只有到運(yùn)行時(shí)才知道.而且并不所有的人都懂?dāng)?shù)據(jù)庫的。LINQ to SQL在一切圍繞數(shù)據(jù)的項(xiàng)目?jī)?nèi)都可以使用。特別是在項(xiàng)目中缺少SQL Server方面的專家時(shí)，LINQ to SQL的強(qiáng)大的功能可以幫我們快速的完成項(xiàng)目。LINQ to SQL的推出，是讓大家從煩瑣的技術(shù)細(xì)節(jié)中解脫出來，更加關(guān)注項(xiàng)目的邏輯。LINQto SQL的出現(xiàn)，大大降低了數(shù)據(jù)庫應(yīng)用程序開發(fā)的門楷，它實(shí)質(zhì)是事先為你構(gòu)架了數(shù)據(jù)訪問層，勢(shì)必將加快數(shù)據(jù)庫應(yīng)用程序的開發(fā)進(jìn)度。LINQ to SQL解放了眾多程序員，讓他們的把更多的精力放到業(yè)務(wù)邏輯以及code上，而不是數(shù)據(jù)庫。對(duì)于初學(xué)者來講，LINQ to SQL可以讓他們迅速進(jìn)入數(shù)據(jù)庫應(yīng)用程序開發(fā)領(lǐng)域，節(jié)約了培訓(xùn)成本。

LINQ to SQL的實(shí)現(xiàn)，是在ado.net和C#2.0的基礎(chǔ)上的。它通過自動(dòng)翻譯SQL語句，并把結(jié)果集創(chuàng)建成對(duì)象并返回。這里我們可以看出，發(fā)送到SQLServer端的SQL語句是LINQ to SQL自動(dòng)生成的。這對(duì)不懂SQL的人來說，無疑是個(gè)福音。第二，LINQ to SQL語句是在編譯期間就做檢查的。而不是運(yùn)行時(shí)檢查。這樣，那里出了問題，可以及時(shí)更改，而不是到了運(yùn)行時(shí)才發(fā)現(xiàn)問題。第三，LINQ to SQL是針對(duì)對(duì)象操作的，更符合今天的oo呼聲。

在LINQ to SQL之前，在Java領(lǐng)域有Hibernate，在net領(lǐng)域有NHibernate技術(shù)，來實(shí)現(xiàn)object/relational持久和查詢服務(wù)。那和NHibernate比起來，它又有那些優(yōu)勢(shì)呢.第一，影射代碼自動(dòng)生成。VS2008提供了SQLMetal和ORDesigner兩個(gè)工具來完成此步驟。而在NHibernate中，你不得不自己手工寫。第二，影射代碼有更多的選擇.NHibernate只能把數(shù)據(jù)庫的信息配置在一個(gè)xml中，而LINQ to SQL有兩種方式，一個(gè)是放到XML中，我們稱為Externl Mapping,再一種就是以Attribute的形式，存在于各個(gè)property中。當(dāng)然，筆者本人并沒有使用過NHibernate，只是從資料上得到這些消息，所以無法給出更多的比較。

2、LINQ to SQL的缺點(diǎn)

很久前，有個(gè)網(wǎng)友問到這么一個(gè)問題。他在界面上有個(gè)DataView，里面綁定了一些Column，然后他勾選那一列就按某列排序。其傳回的參數(shù)是列的名字。然后問我該怎么用DLINQ 來實(shí)現(xiàn)。

在以前拼接SQL語句的年代，這個(gè)很簡(jiǎn)單，一個(gè)" order by " + string，想按什么排就按什么來排。而現(xiàn)在dLINQ是用是一個(gè)對(duì)象的屬性，已經(jīng)不可能拼接了。我當(dāng)時(shí)給他的答案是這樣的。

以下是引用片段：

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(); 
}

我那時(shí)也沒有想出一個(gè)更好的方案來。而后告訴他去查下Compiled Query，說不定可以找到更方便的。后來我才在這個(gè)例子中，看到更方便的。

以下是引用片段：

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換成小寫的，一跑過了。莫非真的是列的名字?出個(gè)難題吧。找了一個(gè)列名，是帶空格的，重新來建這個(gè)工程.一跑，錯(cuò)了!把列名用中國(guó)擴(kuò)號(hào)擴(kuò)起來了，也是錯(cuò)了?？龋皇莿?dòng)態(tài)構(gòu)造ExpressionTree而已，永遠(yuǎn)都不能直接接收列的名字。這個(gè)例子看著是很簡(jiǎn)單，可不知道你有沒有注意到它有一個(gè)80多k的Dynamic.cs文件。更有意思的事情是，它的名稱空間是System.LINQ.Dynamic.看樣子，ms本來是打算把它加在.net3.5中嗎.不曉得為什么放到了例子中了。這個(gè)名稱空間下，其主要內(nèi)容就是動(dòng)態(tài)構(gòu)造Expression Tree. 和LINQ to SQL進(jìn)階系列(七)動(dòng)態(tài)查詢一文中的方法類似。只是，它還包含了解析字符串部分.

從上面那個(gè)例子中，可以看出，LINQ to SQL在這種動(dòng)態(tài)構(gòu)造語句時(shí)，比拼接SQL麻煩很多。在LINQ to SQL進(jìn)階系列(七)動(dòng)態(tài)查詢一文中，筆者極力推薦使用object的查詢。這符合LINQ to SQL的設(shè)計(jì)原則。因?yàn)?，它主要是為了解決data!=objects的問題而產(chǎn)生的.它所有的操作均針對(duì)object，那就讓我們使用object的查詢吧.

當(dāng)然，依然會(huì)有人習(xí)慣拼接字符串.我并不認(rèn)為這是個(gè)壞毛病。只是有點(diǎn)不符合oo思想而已。事實(shí)上，在LINQ to SQL中，你依然可以使用拼接字符串的形式，而不使用它提供的QueryExpression. 它提供了這么兩個(gè)接口，一個(gè)是，db.ExecuteQuery(string SQL);另一個(gè)是，db.ExecuteCommand(string　SQL);這兩個(gè)函數(shù)都是直接接收　SQL語句的.習(xí)慣拼接的人，依然可以調(diào)用它們來實(shí)現(xiàn)你的程序。特別是第一個(gè)，其返回的就是一個(gè)對(duì)象的集合，多少還是有點(diǎn)oo思想的。

看下面的例子：

以下是引用片段：

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吧，再看下面這個(gè)：

以下是引用片段：
db.ExecuteCommand("UPDATE Products SET UnitPrice = UnitPrice + 1.00");

它在做批處理的時(shí)候，你想不用它，都不行.當(dāng)然，你如果覺得性能不是問題的話，那就用submitchange方法來做更新好了。簡(jiǎn)單明了的說，LINQ to SQL在批處理更新的時(shí)候，SubmitChange只會(huì)一個(gè)個(gè)的更新。浪費(fèi)時(shí)間資源.而這個(gè)接口，恰好滿足了批處理更新或刪除的問題。從這兩個(gè)例子，我們可以看出。沒有任何方案是萬能的。各有各的優(yōu)點(diǎn)。

3、LINQ to SQL的性能

LINQ的性能已經(jīng)被好多人提及.LINQ to Object的性能大家討論的比較多些.它確實(shí)比自己實(shí)現(xiàn)的查找要慢.但是當(dāng)數(shù)據(jù)量特別大時(shí)，更多是時(shí)間是花在分配虛擬內(nèi)存上了，那么他們的差別就不是那么明顯了。LINQ to SQL是又如何提升性能的?第一，采用延遲加載(deferredloading)技術(shù)。語句是聲明了，但是并不立即執(zhí)行，而是在真正需要的時(shí)候才執(zhí)行。第二，采用緩存技術(shù)。已經(jīng)取到內(nèi)存的數(shù)據(jù)，再依次提取時(shí)，會(huì)先從緩存中返回，而不是再次訪問數(shù)據(jù)庫。當(dāng)然，筆者建議，不要對(duì)象的時(shí)候，沒有必要使用LINQ to SQL.比如，只是填充DataView或DataGrid時(shí)，返回dataset或datatable要比用LINQ to SQL實(shí)現(xiàn)的快很多。

結(jié)論：各種技術(shù)都有其自身的優(yōu)點(diǎn)和缺點(diǎn)。使用什么樣的技術(shù)，完全在于項(xiàng)目對(duì)性能和開發(fā)進(jìn)度的要求，以及程序員自身的愛好有關(guān)。揚(yáng)長(zhǎng)避短，才是正道。