LINQ To SQL的N-Tier分析
LINQ To SQL有很多值得學(xué)習(xí)的地方，這里我們主要介紹LINQ To SQL N-Tier，包括介紹.NET Framework 3.5下的N-Tier等方面。
當(dāng)初，LINQ之所以會吸引我目光的原因有二，一是其與語言整合的奇想，讓我覺得相當(dāng)?shù)男迈r且有創(chuàng)意，二則是ORM的誘惑，多年來，我一直對 ORM有著相當(dāng)高的興趣，從研究ORM概念到使用ORM產(chǎn)品，乃至于自行開發(fā)ORM Framework，對于這個技術(shù)，我有著深入的研究及無限的渴望。
做為Microsoft第一個公開的ORM實作體，LINQ To SQL不管是于效率還是易用性上，都有著不俗的表現(xiàn)，但在N-Tier應(yīng)用上，LINQ To SQL卻一直處于相當(dāng)不明確的狀態(tài)，即使到了Visual Studio 2008正式上市的今天，仍然沒有一個完整的文件及范例，告訴我們?nèi)绾螌INQ To SQL應(yīng)用于N-Tier系統(tǒng)架構(gòu)中，本系列文章將以一個小型的N-Tier范例做為結(jié)尾，為讀者們演示，如何將LINQ To SQL應(yīng)用于以WPF做為UI層的N-Tier系統(tǒng)架構(gòu)上。
LINQ To SQL N-Tier應(yīng)用
在開始討論LINQ To SQL N-Tier之前，我們得先定位出什么是N-Tier應(yīng)用程式，說穿了，LINQ To SQL N-Tier系統(tǒng)架構(gòu)就是于傳統(tǒng)的Client/Server架構(gòu)中添加一臺架設(shè)應(yīng)用程式伺服器的電腦，做為橋接Client端與Server端(也就是架設(shè)資料庫系統(tǒng)的那臺電腦)的中介者。那為何要這么做呢？主要原因有兩個，一是擴充性的考量：在傳統(tǒng)的Client/Server架構(gòu)中，Server端必須負擔(dān)服務(wù)所有客戶端的重責(zé)大任，一旦客戶端增多，Server端電腦的等級也必須隨之提升，否則效能會因大量的客戶端而降低，架設(shè)中介伺服器可以分擔(dān)原本由Server端一手包辦的工作。
在面對大量使用者同時操作系統(tǒng)的情況下，中介伺服器可以快取部份常用的資料，以暫存方式來取代真正的資料庫操作，進而減輕Server端的負擔(dān)。在N-Tier架構(gòu)中，中介伺服器并不僅限于一臺電腦，這意味著我們可以架設(shè)多臺中介伺服器，然后讓Client端連往主控的中介伺服器，再由此中介伺服器決定該Client端是要連往那一臺中介伺服器，這也是N-Tier用語中常見的『負載平衡』。
二是安全性的考量：原本在Client/Server架構(gòu)中，Client端是直接與Server端溝通的，這意味著如果應(yīng)用程式需要透過網(wǎng)際網(wǎng)路來連結(jié)Server時，該Server就必須曝露于網(wǎng)際網(wǎng)路上才行，但這個Server端通常是一個架設(shè)資料庫系統(tǒng)的電腦，將整個公司重要的資料曝露于眾人可及的網(wǎng)路上，相信沒有幾家公司有這個勇氣或膽識吧。
借助于中介伺服器的架設(shè)，可讓后端資料庫免除于曝露于網(wǎng)路上的危機。而Client端與中介伺服器間的溝通立基于有限的通訊規(guī)格，所以即使中介伺服器需曝露于網(wǎng)際網(wǎng)路上，有心人士透過中介伺服器來傷害后端資料庫的機會及層次也降低了不少，何況通訊加密是所有N-Tier應(yīng)用程式必須實作的部份，比起簡單的資料庫通訊協(xié)定，專為N-Tier應(yīng)用程式所設(shè)計的安全通訊協(xié)定如Web Services，自然安全許多。
.NET Framework 3.5下的N-Tier
當(dāng)決定采用N-Tier架構(gòu)時，Client端與中介伺服器間的通訊協(xié)定便成了第一個得做出的選擇，從.NET Framework 3.0開始，Microsoft便致力于打造新一代可用于N-Tier架構(gòu)的通訊協(xié)定：Windows Communication Foundation，簡稱WCF。在原始的設(shè)計概念中，WCF必須解決兩個問題，一是效率的問題，以往的N-Tier程式可分成兩大陣營，一是使用公開的標準規(guī)格：Web Services做為通訊協(xié)定，二是使用封閉的規(guī)格：Remoting。由于可使用Binary(二進位)協(xié)定來封裝訊息，所以Remoting在效能上有著相當(dāng)耀眼的表現(xiàn)，但Remoting是封閉的協(xié)定，所以失去了與其它平臺互通的可能性。使用Web Services雖然可以得到了平臺互通的特色，但卻必須以效率做為交換條件。
WCF在訊息封裝層做了一個抽象化的設(shè)計，可以讓W(xué)CF應(yīng)用程式于執(zhí)行時期切換使用的通訊協(xié)定，這也就是說，當(dāng)在網(wǎng)路環(huán)境良好，且沒有平臺互通性考量的情況下，我們可以在不重新編譯應(yīng)用程式的狀態(tài)下，僅修改組態(tài)檔就能將架構(gòu)于WCF的應(yīng)用程式之通訊層換成Binary格式，當(dāng)需要互通性時，也只要修改組態(tài)檔就能改為Web Services格式，此項設(shè)計讓W(xué)CF應(yīng)用程式可以輕松游走于兩種通訊協(xié)定間，不像以往般，一旦選擇了Remoting后，要改成Web Services就很難了。
WCF出現(xiàn)的第二個目的是要實作更多的Web Services規(guī)格，這幾年來Web Services的規(guī)格鋪天蓋地的出現(xiàn)，能支援更多的規(guī)格代表著與其它平臺的互通性也就越高，WCF中支援了如WS-Security、WS- ReliableMessage、WS-Coordation、WS-Address等新規(guī)格。因此，在.NET Framework 3.5中，不管是依據(jù)效能或是互通性的考量，WCF都是最好的選擇。
【編輯推薦】
