剖析 .Net 下的資料訪問層技術(六)

來源:互聯網
上載者:User
訪問|資料 u 其它

Ø ASTA

經常在Delphi下進行網路資料庫應用開發或者曾經使用過Borland Midas技術的朋友,對ASTA應該不會陌生。

如果說基於ADO.NET或O/R Mapping來實現DAL是少林、武當的正宗心法,那ASTA就有點明教“乾坤大挪移”的味道:將整個DAL中的Data Access幾乎完全扔到了另一個地方(和打回原處稍有區別,但也算另一種挪移J)進行處理!



傳統的DAL實現大都是這樣的:




ASTA則另闢蹊徑,額外加入了一個“中介層”:




一般來說,中介層的引入是為了提高靈活性,減少耦合度,

ASTA就是利用了這個特性設計出來的。

上圖的一個關鍵點就在於ASTA Client與ASTA Server之間

的那個“網路連接”,ASTA技術正是利用了網路特性,間接地

屏蔽了不同資料庫系統間的差別,使開發人員在設計DAL時完

全不用知道Database的存在!這種情況有點像瀏覽器,完全不

用知道HTML頁面是來自於IIS還是Apache,只需要知道自己

是利用HTTP協議通過網路來獲得HTML頁面!



在ASTA中,瀏覽器就是ASTA Client,HTML頁面就是ASTA DataSet(與ADO.NET中的DataSet在格式上有區別,此處可以認為是另一種資料庫無關的資料集合表示方式),而IIS、Apache就是ASTA提供的不同的ASTA Server(目前支援大部分主流資料庫系統,開發人員也可以撰寫自己的ASTA Server),HTTP協議自然就是ASTA Client與ASTA Server間的通訊協定!

從技術上分析,ASTA架構的目的之一就是利用自己提供的協議來屏蔽不同資料庫系統的網路通訊協定,從而使用戶端(DAL)完全擺脫在編寫網路資料庫應用時的通訊難題!

(作者還記得,.NET出來前,每次在編寫面向Internet 的SQL Server應用程式時,除了需要配置連接字串,還要在用戶端特別安裝SQL Server Client Network Utility以配置Internet串連,不說SQL Server暴露連接埠引起的安全問題,就是這麼一番折騰也讓人夠嗆的J)



在ASTA下編寫程式非常舒服,只要知道ASTA Server的地址和連接埠,再提供一定許可權的使用者名稱、口令(ASTA內建的認證系統,開發人員也可以撰寫自己的Authentication/Authorization模組,甚至直接利用資料庫系統提供的驗證機制),立刻就能得到任何資料庫的任何資料資訊!而且,一旦資料庫系統有所變動(如從SQL Server切換到Oracle,但不包括資料庫結構的改動),用戶端根本無須任何修改!

ASTA技術不足處也是很明顯的:由於引入了在某些情況下

(如一次返回資料量很大時)足以致命的“網路中介層”,使開

發人員在開發大型應用(尤其是面向Internet的企業級應用)時

需要特別小心,畢竟,舒服在某些時候是需要付出一定代價的!



有興趣的朋友不妨去這個網站看看:

http://www.astatech.com



Ø .NET Remoting / WebServices

原來不準備將.NET Remoting / WebServies拿出來湊熱鬧,畢竟,這兩種技術不是為DAL度身定做的。

無奈,偏偏就是看到有朋友這麼用過,後來細想,發現也頗有一些道理,就拿出來與大家一起參詳參詳。

其實,雖然微軟大肆宣傳XML WebServices,但就技術來看,其實只要論述.NET Remoting一種就可以了,XML WebServices無非就是在.NET Remoting中使用了HTTP + SOAP通訊協定的一種特例而已。



.NET Remoting應用到DAL中可能出於兩種目的:

(1) 希望實現跨平台資料訪問,因為ADO.NET中的DataSet是可以被序列化的,通過Remoting或WebServices可以在用戶端恢複現場;



(2) 減輕伺服器壓力,增加系統靈活性。

這有點類似於上面的ASTA技術,只不過這裡的協議

換成了.NET Remoting Protocal。但即使用這種方式,

還是和ASTA的靈活性有區別,畢竟,Remoting要

求在用戶端註冊每一個DAL的提供者,一旦介面

變化,介面必須重新註冊!



所以,作者的建議是:盡量避免使用.NET Remoting來

構建應用程式的DAL模組(如果是Business Logic Layer,則不

存在這個問題),除非真的是“迫不得已”(例如:必須在DAL

層實現分散式運算或者客戶堅持使用.NET Remoting J)!





以下部分因時間限制,正在撰寫中 !

l 我的方案(未完,撰寫中……)

u 綜合現有的技術

Ø 在DAL之上添加一個新的DAF Layer:Data Access Facade

n 使用DataSet / DataTable / DataView + Cache Management

n 使用ObjectSpaces / ECO + ADO.NET + Stored Procedure

Ø ……

u 使用現成的架構

Ø 開源項目推薦使用OPF(國外)

Ø 商業產品推薦使用Grove(國內)

Ø ……

u 設計自己的持久層

Ø 如果希望自己設計輪子,那麼,最好的參考資料莫過於這篇文章:http://www.ambysoft.com/persistenceLayer.pdf

Ø ……



l 小結(未完,撰寫中……)

l 參考(未完,撰寫中……)





相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。