LINQ to SQL全面概述
在向大家詳細(xì)介紹LINQ to SQL之前，首先讓大家了解下LINQ to SQL不能算純粹意義上的ORM，因為它支持的數(shù)據(jù)庫種類和類型還不夠多，然后全面介紹LINQ to SQL。
LINQ to SQL 目前只支持SQL Server(SQL Server Compact版本正在開發(fā)中)，有跡象表明，也可能會支持DB2，Informix IDS，Oracle官方說法是他們在關(guān)注Linq的進(jìn)展，VistaDB， MySQL。。。但可以預(yù)見的是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ù)的先進(jìn)性和難度來看，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ù)氖虑椋詮脑O(shè)計上來看，LINQ更大氣和宏觀，因為一旦從編譯器和開發(fā)語言的層面的支持，那么其融合滲透和應(yīng)用的程度就相當(dāng)高的，我認(rèn)為其"親和力"相當(dā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上)，甚至有人認(rèn)為Orcas's Entity Framework 進(jìn)度的重大的標(biāo)志在于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)說的比較清楚(思?xì)w翻譯的版本)，我總結(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無法達(dá)到這樣的效果，另外LINQ to Entities也直接帶有了ADO EF提供的另外一些強項，比如實體的繼承(Entity Inheritance )，實體的組合(Entity Composition)
Entity SQL (eSQL)更多的時候，它是SQL語句的變體是完全面向查詢語言的(Query Language)，但是是對應(yīng)的是對實體數(shù)據(jù)模型的查詢，是對實體，實體中的屬性進(jìn)行查詢，更多的時候Entity SQL 是面對ADO EF的Object Services，對象服務(wù)是ADO EF中能夠?qū)嶓w像對象一樣工作和操作的服務(wù)，事實上Object Services往往是事實上的內(nèi)存對象數(shù)據(jù)庫，當(dāng)然在這里你只能查詢對象或?qū)嶓w并獲得它們，你不能是使用SQL DML語句一樣，Update或Deleted對象或?qū)嶓w(當(dāng)然未來可以，現(xiàn)在v1版本是做好查詢)，當(dāng)我們要和上面說的概念層/實體層交互的時候，***你可以使用Entity SQL (eSQL)，第二你要使用LINQ to Entities，Entity SQL (eSQL)是文本和字符的，所以它支持組合(composable)，比如子查詢，而后你明白所有的LINQ to XXXX，其實就是說你如何讓你在編程語言這個層面，很快地享受到LINQ針對XXXX(數(shù)據(jù)源或?qū)ο笤?的數(shù)據(jù)集成和查詢的能力以及便利(內(nèi)置的表達(dá)式，操作語句，代碼生產(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ù)進(jìn)行嫻熟地處理，抑或是如拌涼菜般地翻騰這些數(shù)據(jù)。
作為一個顧問和實踐者，我們首先要去做，然后要面臨給予自己和其他的人一些建議，在未來的6個月到一年：
1. LINQ的出現(xiàn)展示了一種***層的新型張力，任何現(xiàn)代編程語言最重要的能量和動力在這個語言的編譯器，LINQ的出現(xiàn)讓所有有關(guān)語言先進(jìn)性爭論的時代劃句號，作為技術(shù)人員你需要察覺到這種變化和帶來的影響
2. 從目前的Orcas Beta1版本來看，建議你在未來的6-12月優(yōu)先學(xué)習(xí)C# 3.0和LINQ，掌握新型的表達(dá)式、語法和語句，這是未來編程語言中和For,IF語句一樣的基本功，而每個開發(fā)人員需要熟練的使用這些語句，當(dāng)然能夠研究和搞明白這些新語句的背后的實現(xiàn)和原理，那是***的
3.對于那些已經(jīng)掌握C#3.0和LINQ的中級的開發(fā)人員來說，在LINQ to SQL(LINQ2SQL)和ADO.NET Entity Framework來說，可以優(yōu)先考慮學(xué)習(xí)和研究LINQ to SQL，并將其這種技術(shù)在項目或應(yīng)用中做以實踐
4.ADO.NET Entity Frameworkd的 Entity Desiger出來之前，保持對它的關(guān)注，而不用花太多的時間，另外從一個開發(fā)人員的角度來看，ADO EF不是必須的，甚至在設(shè)計人員特別是Domain Model Drivening的人員要關(guān)注和準(zhǔn)備的，當(dāng)然這些在6個月之后考慮和研究都不晚
5.Visual Studio Orcas的發(fā)布日期依然是一個很關(guān)鍵的因素，可以預(yù)見的是C# 3.0和LINQ將會在人們期望和愿望實現(xiàn)的時間點發(fā)布，但涉及到ADO.NET Entity Framework的部分有多少，這個要觀察和注意，但反過來說，有了LINQ和LINQ to SQL已經(jīng)讓我們感到物有所值了
6.在你的項目中考慮新的功能特性對應(yīng)用架構(gòu)的影響，同時也盡可能多練習(xí)在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)開始走向更成熟，先進(jìn)和自信的一面
【編輯推薦】
