2008-08-06 120 views
9

我目前正在開發一個具有特定需求的項目。是這些的簡要概述如下:基於計時器的事件觸發器

  • 數據從外部web服務檢索
  • 的數據存儲在SQL 2005
  • 數據經由web GUI
  • Windows服務與所述連通操縱除了通過數據庫之外,Web服務與我們的內部Web UI沒有耦合。
  • 與Web服務的通信需要基於時間,並通過用戶在Web UI上的干預來觸發。

用於網絡服務的通信的觸發電流(預預生產)模型是通過其存儲觸發從人工干預產生的請求的數據庫表。我真的不想有多個觸發機制,但希望能夠根據調用時間使用觸發器填充數據庫表。正如我所看到的,有兩種方法可以實現這一點。

1)調整觸發表以存儲兩個額外的參數。一個是「這是基於時間還是手動添加?」和一個可爲空的字段來存儲時間細節(確切格式待定)。如果它是一個經過手工創建的觸發器,則在觸發器被觸發時將其標記爲已處理,但如果它是定時觸發器則不予處理。

2)創建第二個windows服務,以定時的間隔即時創建觸發器。

第二個選項對我來說似乎是一個騙局,但是選項1的管理很容易變成編程惡夢(你怎麼知道表的最後一次投票是否返回了需要觸發的事件,以及如何執行你然後停止它在下一次民意調查中重新觸發)

如果任何人可以騰出幾分鐘的時間來幫助我決定採取哪種路線(其中一個,或者可能是三個未列出的路線),我將不勝感激。 。

回答

1

爲什麼不使用SQL作業而不是Windows服務?你可以將所有的db「觸發」代碼封裝在Stored Procedures中。然後,您的UI和SQL作業可以調用相同的存儲過程,並以相同的方式創建觸發器,無論是手動還是間隔。

0

我看到它的方式是這樣的。

你有一個Windows服務,它扮演一個調度程序的角色,並且它有一些類只是調用Web服務並將數據放入數據庫中。

所以,你可以在WebUI中直接使用這些類以及和導入基於WebUI的觸發數據。

我不喜歡在數據庫中存儲用戶生成的操作作爲標誌(觸發器)的想法,其中某些服務將輪詢它(在不受用戶控制的時間間隔內)以執行該操作。

你甚至可以將整個代碼轉換成一個exe,然後你可以使用Windows Scheduler進行調度。並且每當用戶從Web UI觸發操作​​時調用相同的exe。

0

@Vaibhav

不幸的是,該解決方案的物理架構不會允許組件之間和數據庫服務的任何直接溝通,比Web UI將數據庫等,(然後可以調出該網絡服務) 。然而,我確實認爲重新使用通信類將是理想的 - 我不能在我們的業務範圍內做到這一點*

*是不是總是這樣一種技術上的「更好的「解決方案受到外部因素的阻礙?