摘要 在本系列文章中，我們將深入探討如何把.NET 2.0和SQL Server 2005的查詢(xún)通知特征聯(lián)合起來(lái)，以便通知應(yīng)用程序何時(shí)關(guān)鍵數(shù)據(jù)發(fā)生變化進(jìn)而達(dá)到消除反復(fù)查詢(xún)數(shù)據(jù)庫(kù)的目的。
一. 引言
數(shù)據(jù)庫(kù)應(yīng)用程序的典型問(wèn)題之一是更新陳舊的數(shù)據(jù)。
設(shè)想有一個(gè)典型的顯示產(chǎn)品及其分類(lèi)的電子商務(wù)網(wǎng)站。一個(gè)供應(yīng)商的產(chǎn)品列表很可能并不經(jīng)常發(fā)生變化，而其分類(lèi)列表甚至更不會(huì)頻繁更改。然而，在用戶(hù)每次瀏覽該網(wǎng)站時(shí)，必須從數(shù)據(jù)庫(kù)中反復(fù)查詢(xún)這些列表。這顯然是一種典型的低效資源利用，開(kāi)發(fā)者和架構(gòu)師都在絞盡腦汁想辦法以減少這種浪費(fèi)。
緩沖技術(shù)正是“最小化”對(duì)這種幾乎“停滯”的數(shù)據(jù)進(jìn)行重復(fù)查詢(xún)的技術(shù)之一。這種數(shù)據(jù)可以被進(jìn)行一次性查詢(xún)并存儲(chǔ)在一個(gè)緩沖區(qū)中，而且應(yīng)用程序可以從緩存中重復(fù)地存取數(shù)據(jù)。偶爾情況下，才更新緩存以得到新數(shù)據(jù)。但是，圍繞更新緩存的時(shí)間調(diào)度方面出現(xiàn)了幾個(gè)問(wèn)題。該多長(zhǎng)時(shí)間操作一次呢？例如，你每隔多長(zhǎng)時(shí)間希望你的產(chǎn)品分類(lèi)改變一次？每隔幾個(gè)月一次？每隔兩個(gè)月刷新一次該緩沖區(qū)如何？你知道會(huì)發(fā)生什么嗎？就在你刷新緩存之后，分類(lèi)被更新，而且在下一次刷新前在兩個(gè)月的時(shí)間里它將保持陳舊。
查詢(xún)通知，是微軟的ADO.NET和SQL Server小組協(xié)作開(kāi)發(fā)的新成果。簡(jiǎn)言之，查詢(xún)通知允許你緩沖數(shù)據(jù)并且僅在SQL Server中的數(shù)據(jù)發(fā)生變化時(shí)才發(fā)出通知。一旦接到通知，你就可以刷新你的緩沖區(qū)或者采取你需要的任何措施。
在SQL Server 2005中引入的一種新特征“Service Broker”使得查詢(xún)通知成為可能。Service Broker把隊(duì)列機(jī)制引入到數(shù)據(jù)庫(kù)管理中，它使用一組隊(duì)列與服務(wù)進(jìn)行通訊，而服務(wù)反過(guò)來(lái)也知道如何往回通訊以調(diào)用相應(yīng)的實(shí)體。其實(shí)，這些隊(duì)列和服務(wù)都是一些與表、視圖和存儲(chǔ)過(guò)程一樣的類(lèi)對(duì)象。盡管完全可以在SQL Server內(nèi)使用Service Broker，但是ADO.NET知道如何與Service Broker進(jìn)行通訊以觸發(fā)這種機(jī)制并且從Service Broker中檢索回通知。
注意 當(dāng)SQL Server中的數(shù)據(jù)發(fā)生改變時(shí)，查詢(xún)通知允許你緩沖數(shù)據(jù)并且通知你。
在.NET一端，存在很多種“鉤入”這種功能的方式。ADO.NET 2.0提供了System.Data.SqlClient.SqlDependency和System.Data.Sql.SqlNotificationRequest類(lèi)。SqlDependency是SqlNotificationRequest的一種高級(jí)實(shí)現(xiàn)，并且是當(dāng)使用ADO.NET 2.0時(shí)你最有可能使用的類(lèi)。ASP.NET 2.0也通過(guò)System.Web.Caching.SqlCache-Dependency類(lèi)(它提供了一個(gè)針對(duì)SqlDependency的包裝器)與Service Broker進(jìn)行通訊，而且這是直接通過(guò)在一個(gè)ASP.NET頁(yè)面中使用<%OutputCache>指令以聲明方式提供的功能實(shí)現(xiàn)的。這允許ASP.NET開(kāi)發(fā)者容易地實(shí)現(xiàn)使依賴(lài)于SQL Server中的數(shù)據(jù)中的緩存無(wú)效。
二. .NET與Service Broker的通訊
上面這些技術(shù)是如何聯(lián)合到一起來(lái)解決“緩沖之謎”的呢？盡管你可以采取很多的措施以允許SQL Server把服務(wù)提供給.NET；但是，關(guān)鍵還在于，發(fā)送到SQL Server的查詢(xún)具有一個(gè)依附到它們的標(biāo)志以便告訴SQL Server，除了返回結(jié)果集外，SQL Server還應(yīng)該把該查詢(xún)（及其請(qǐng)求者）注冊(cè)到Service Broker。為此，你要?jiǎng)?chuàng)建一個(gè)感知該查詢(xún)的隊(duì)列和一個(gè)依附到該隊(duì)列的服務(wù)，并且知道如何返回到客戶(hù)端。如果該結(jié)果集中的任何一行在數(shù)據(jù)庫(kù)中得到更新，那么在相關(guān)隊(duì)列中的項(xiàng)將觸發(fā)，并且反過(guò)來(lái)，把一條消息發(fā)送到它的服務(wù)，然后把一個(gè)通知發(fā)送回初始化該請(qǐng)求的應(yīng)用程序。
圖1是SQL Server Management Studio的一個(gè)快照，它顯示了在數(shù)據(jù)庫(kù)的Service Broker部分中的隊(duì)列（Queues）和服務(wù)（Services）。
圖1.該圖顯示了.NET的查詢(xún)通知所使用的Pubs數(shù)據(jù)庫(kù)中的缺省隊(duì)列和服務(wù)。
下面是理解這一過(guò)程的一些有關(guān)重要內(nèi)容：
· 存在一些規(guī)則以指出SQL Server接收哪些類(lèi)型的查詢(xún)。
· 一旦SQL Server發(fā)送回通知，隊(duì)列和服務(wù)即被刪除。這意味著，你僅能在每次請(qǐng)求中得到一個(gè)通知。一個(gè)典型的應(yīng)用程序會(huì)重新查詢(xún)數(shù)據(jù)庫(kù)并且，在同時(shí)，請(qǐng)求在Service Broker中創(chuàng)建一種新的依賴(lài)性。
本新聞共
4頁(yè),當(dāng)前在第
1頁(yè)
1 2 3 4 
