溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

LINQ to SQL有什么用

發(fā)布時間:2021-12-02 09:27:37 來源:億速云 閱讀:104 作者:小新 欄目:編程語言

這篇文章將為大家詳細講解有關(guān)LINQ to SQL有什么用,小編覺得挺實用的,因此分享給大家做個參考,希望大家閱讀完這篇文章后可以有所收獲。

LINQ to SQL 目前只支持SQL Server(SQL Server Compact版本正在開發(fā)中),有跡象表明,也可能會支持DB2,Informix IDS,Oracle官方說法是他們在關(guān)注Linq的進展,VistaDB, MySQL。。。但可以預見的是Linq如果要在2007年底RTM,那么要支持其它數(shù)據(jù)庫的時間上,并不多,甚至我在Weblog上看到說,對SQL Server Compact的支持都不包含在LINQ v1版本計劃中。不過,MS,IBM,Oracle他們?nèi)绻鏇Q心做,那么時間不是問題上面的結(jié)論如果成立,那么我的***觀點是,LINQ to SQL不能算純粹意義上的ORM,因為它支持的數(shù)據(jù)庫種類和類型還不夠多

從技術(shù)的先進性和難度來看,Java Persistence API和Linq是解決不同層面問題的兩種技術(shù),并且從開發(fā)人員的角度來看,Java Persistence API沒有Touch到Linq關(guān)注的層面,上面我說了,從編程語言的角度來看,LINQ是來自***層編譯器和開發(fā)語言的支持,Java Persistence沒這么底層;另外對于Java Persistence API,Adopt已有的ORM技術(shù)比如Hibernate, TopLink, JDO方面,Java Persistence API更像已有Java ORM的集大成者新建的一個API,而LINQ to SQL,LINQ to DataSet,LINQ to XML,LINQ to Entities,LINQ to Object,LINQ to Flickr, LINQ to NHibernate, LINQ to LDAP 已經(jīng)都是板上定釘?shù)氖虑?,所以從設(shè)計上來看,LINQ更大氣和宏觀,因為一旦從編譯器和開發(fā)語言的層面的支持,那么其融合滲透和應(yīng)用的程度就相當高的,我認為其"親和力"相當強悍

ADO.NET Entity Framework(ADO EF)更多的是一個實體或概念設(shè)計的服務(wù)框架,是現(xiàn)實的實體和實體間的關(guān)系映射到將對象層,CLR 類和它們之間的關(guān)系上,甚至ADO.NET Team也避免讓ADO EF概念上變成一個類似ORM的設(shè)計工具,ADO EF強調(diào)的三層{概念層/實體層(Conceptual layer), 元數(shù)據(jù)層(Source schema)和影射層(Mapping layer)}的靈活、獨立和松散耦合,從而使得你可以將一個概念層/實體層通過定義多個影射層從而映射到多個不同的數(shù)據(jù)庫上,而這一點LINQ to SQL做不到,首先LINQ to SQL不支持實體的多重繼承(支持有限的繼承),甚至有評論說LINQ to SQL RTM之前都不會獲得many-many relationships的支持,LINQ to SQL更多的是使用dbml屬性非常緊耦合地綁定到一張表的某些特定的數(shù)據(jù)庫字段上。也就是說LINQ to SQL沒有這么多層,另外它強調(diào)的是編程語言對數(shù)據(jù)查詢和分析的結(jié)構(gòu)化支持(從編程語言的層面)

理論上ADO EF是一個浩大大工程的框架,從而能夠更好的支持流行的Domain Model Driven的開發(fā),這要求它要有三層的設(shè)計工具展現(xiàn)你的設(shè)計,突現(xiàn)和定位你的實體關(guān)系,要求工具能夠根據(jù)實體層產(chǎn)生數(shù)據(jù)庫的腳本或是反向工程,同時需要有精度極高同時有非常Smart的代碼生成工具和界面,同時,而目前Orcas Beta1單薄的的EDM Wizard根本不足以完成這些要求,更早先發(fā)布的Entity Data Model Designer Prototype已經(jīng)成為豐碑快不可超越,看看這里有比較漂亮的一個設(shè)計器的錄像--很酷

“Entity Framework the March CTP and Beta 1 are almost identical. There's some last bit of features that we're busily working on now that will appear in Beta 2 and the Orcas Release”這意味著Orcas Beta1和March CTP中 ADO EF變化并不大(ccBoy建議:在Orcas Beta1你可以精力重點放在 LINQ to SQL上),甚至有人認為Orcas's Entity Framework 進度的重大的標志在于Orcas能夠提供出優(yōu)良的EDM Designer,滿足我們上面說的工程需求,所以O(shè)rcas Beta2將是ADO EF的一個重大里程碑,所以結(jié)論是,ADO EF和 LINQ to SQL側(cè)重點上看兩者的關(guān)注點非常不同,相比來說ADO EF開發(fā)或性能上會奔重些,但是ADO EF傾向Domain Model Driven和支持更多的流行的數(shù)據(jù)庫或數(shù)據(jù)源,但ADO EF絕對不是一個簡單的ORM Tools,理解成實體框架和對象服務(wù)層技術(shù)會更宏觀,這里面LINQ成為ADO EF中很小的一個低層支撐技術(shù),我剛剛說了LINQ的親和力

從技術(shù)開發(fā)的角度來看,如果你的實體/業(yè)務(wù)模型(或者稱為問題域)和已有的數(shù)據(jù)模型不匹配的時候,你需要考慮ADO EF,反正如果你的實體/業(yè)務(wù)模型(或者稱為問題域)和已有的數(shù)據(jù)模型匹配,那么LINQ to SQL 會是不錯的選擇至于LINQ to Entities和LINQ to SQL,上文已經(jīng)說的比較清楚(思歸翻譯的版本),我總結(jié)一下,相同點是,LINQ to Entities是LINQ to SQL的一個超集或加強版(Superset),你看到兩者的Feature對比上,LINQ to Entities更重,它運行或說讓你在一個概念數(shù)據(jù)模型上(Conceptual data model),你對對象的查詢是發(fā)生在這一層

那么不同的地方在于,你使用LINQ to SQL的時候,你的映射,產(chǎn)生的CLR/.NET類是和你的數(shù)據(jù)/數(shù)據(jù)庫模型緊耦合或綁定的,如果你改變對象模型,那么你要直接修改這些類,同樣如果數(shù)據(jù)模型改變,你要使用重新生成對象代碼,而ADO EF在數(shù)據(jù)/數(shù)據(jù)庫模型上建立一個概念層/實體層,這使得你要先定義概念層/實體層,接著建立數(shù)據(jù)/數(shù)據(jù)庫的腳本(描述),然后在一個影射層建立你的實體和數(shù)據(jù)之間的邏輯映射,這使得業(yè)務(wù)和數(shù)據(jù)源之間有了很好的藕合度和隔離。而LINQ to SQL無法達到這樣的效果,另外LINQ to Entities也直接帶有了ADO EF提供的另外一些強項,比如實體的繼承(Entity Inheritance ),實體的組合(Entity Composition)

Entity SQL (eSQL)更多的時候,它是SQL語句的變體是完全面向查詢語言的(Query Language),但是是對應(yīng)的是對實體數(shù)據(jù)模型的查詢,是對實體,實體中的屬性進行查詢,更多的時候Entity SQL 是面對ADO EF的Object Services,對象服務(wù)是ADO EF中能夠?qū)嶓w像對象一樣工作和操作的服務(wù),事實上Object Services往往是事實上的內(nèi)存對象數(shù)據(jù)庫,當然在這里你只能查詢對象或?qū)嶓w并獲得它們,你不能是使用SQL DML語句一樣,Update或Deleted對象或?qū)嶓w(當然未來可以,現(xiàn)在v1版本是做好查詢),當我們要和上面說的概念層/實體層交互的時候,***你可以使用Entity SQL (eSQL),第二你要使用LINQ to Entities,Entity SQL (eSQL)是文本和字符的,所以它支持組合(composable),比如子查詢,而后你明白所有的LINQ to XXXX,其實就是說你如何讓你在編程語言這個層面,很快地享受到LINQ針對XXXX(數(shù)據(jù)源或?qū)ο笤?的數(shù)據(jù)集成和查詢的能力以及便利(內(nèi)置的表達式,操作語句,代碼生產(chǎn)效率,性能等等)

***是Entity Client,這個一個新型的API,也就是專門用來訪問實體源或?qū)嶓w數(shù)據(jù)模型,Entity Client使用自己的語言-Entity SQL (eSQL),它也是ADO.NET提供的另外一個數(shù)據(jù)源提供驅(qū)動,你可以用理解SqlClient一樣來理解Entity Client,它是另外一條訪問實體數(shù)據(jù)模型的途徑,它存在的意義有兩個,***它的訪問性能會高,第二,EntityClient返回的結(jié)果是 dbDataReader,這意味著你可以使用統(tǒng)一或者你非常熟悉的代碼經(jīng)驗比如你使用ADO.NET操作 SQL Server, Oracle,MySQL的技能對查詢回來的數(shù)據(jù)進行嫻熟地處理,抑或是如拌涼菜般地翻騰這些數(shù)據(jù)。

作為一個顧問和實踐者,我們首先要去做,然后要面臨給予自己和其他的人一些建議,在未來的6個月到一年:
1. LINQ的出現(xiàn)展示了一種***層的新型張力,任何現(xiàn)代編程語言最重要的能量和動力在這個語言的編譯器,LINQ的出現(xiàn)讓所有有關(guān)語言先進性爭論的時代劃句號,作為技術(shù)人員你需要察覺到這種變化和帶來的影響
2. 從目前的Orcas Beta1版本來看,建議你在未來的6-12月優(yōu)先學習C# 3.0和LINQ,掌握新型的表達式、語法和語句,這是未來編程語言中和For,IF語句一樣的基本功,而每個開發(fā)人員需要熟練的使用這些語句,當然能夠研究和搞明白這些新語句的背后的實現(xiàn)和原理,那是***的
3.對于那些已經(jīng)掌握C#3.0和LINQ的中級的開發(fā)人員來說,在LINQ to SQL(LINQ2SQL)和ADO.NET Entity Framework來說,可以優(yōu)先考慮學習和研究LINQ to SQL,并將其這種技術(shù)在項目或應(yīng)用中做以實踐
4.ADO.NET Entity Frameworkd的 Entity Desiger出來之前,保持對它的關(guān)注,而不用花太多的時間,另外從一個開發(fā)人員的角度來看,ADO EF不是必須的,甚至在設(shè)計人員特別是Domain Model Drivening的人員要關(guān)注和準備的,當然這些在6個月之后考慮和研究都不晚
5.Visual Studio Orcas的發(fā)布日期依然是一個很關(guān)鍵的因素,可以預見的是C# 3.0和LINQ將會在人們期望和愿望實現(xiàn)的時間點發(fā)布,但涉及到ADO.NET Entity Framework的部分有多少,這個要觀察和注意,但反過來說,有了LINQ和LINQ to SQL已經(jīng)讓我們感到物有所值了
6.在你的項目中考慮新的功能特性對應(yīng)用架構(gòu)的影響,同時也盡可能多練習在ASP.NET這種傳統(tǒng)的開發(fā)技術(shù)下LINQ和C# 的應(yīng)用
7.繼續(xù)保持對Visual Studio Orcas的關(guān)注,因為.NET 3.5或.NET 4.0已經(jīng)開始走向更成熟,先進和自信的一面

關(guān)于“LINQ to SQL有什么用”這篇文章就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,使各位可以學到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。

向AI問一下細節(jié)

免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI