2017-08-18 90 views
-2

我在這裏尋找更多關於概念性想法的討論,而不是必須的細節(雖然具體細節當然也是受歡迎的)。應用程序環境中的頻繁需求是需要能夠按照設定的時間表運行特定任務(每週一下午3:00,每週工作日下午6:30,今天下午2:00等)。處理任務計劃

現在,在我的環境中,我構建了一個在應用程序服務器上運行的Windows服務來處理這些事件。目前它使用一個每小時過期一次的計時器,並檢查是否需要做任何事情。目前,所有這些活動都使用硬編碼的日期/時間/週日等檢查來執行其任務。現在,顯然,使用每小時運行一次的計時器,我解決事件的運行時間是從計劃到1小時後的任何時間。對於我目前的任務來說,這很好。

我想要做的是能夠處理任意計劃的任務,並且在時間上有更好的解決方案。現在,改進的分辨率將只是一個計時器,每分鐘到期檢查一次任務是否需要運行。但是,第一個要求是能夠隨意安排這些事情,這有點複雜。

該應用程序連接到SQL數據庫,並且前端都在基於Web的ASP.Net應用程序中,所以用戶界面部分不應該成爲問題。我想知道以下內容:

我希望至少能夠處理SQL Server代理程序等應用程序所允許的複雜性的日程表,也就是說,允許具有開始日期和結束日期的循環項目或沒有結束日期),頻率(每天,每週,每月),特定的工作日可選擇每週計劃等。現在,顯然,我可以爲數據庫表中的每個元素都有一個字段,還有一個「last運行時間「和」下一次運行時間「列,但這對我來說似乎非常低效。

所以我的具體問題是: 是否有存儲計劃任務的數據庫數據模型設計的最佳做法?

是否有任何現有的.Net庫可用於在前端存儲這些時間表,然後確定是否應該在後端運行特定作業?我當然可以蠻橫地強制這一點,但它似乎是一個普遍的要求,即應該可能會有一些事情要做很多繁重的工作,而不必「重新創建輪子」。

處理這種類型的需求有什麼缺陷,您遇到過,可能不明顯?

回答

0

只使用SQL代理?或者使用Windows計劃任務...也可以考慮Hangfire

您從編寫自己的作品中受益多大?

這是一個更難的問題,它似乎應該利用現有的解決方案。您目前每分鐘投票的想法效率非常低,在處理像這樣的計時時存在許多微妙的錯誤。只需將您的作業寫入控制檯應用程序而不是服務,然後從現有調度程序調用它。如果要保留自定義前端,可以使用SQL Agent/Scheduled Task/Hangfire界面使前端創建作業。

Windows服務更適合於所有時間運行,而不是按計劃運行。