用於長時間運行的Windows服務的實體框架體系結構

我有一個問題，如何在Windows服務中使用實體框架來最好地構建我的解決方案。用於長時間運行的Windows服務的實體框架體系結構

我想提供一個在線（基於web）服務，它允許用戶執行可能長時間運行的任務，看任務的進度，取消它們，等

到目前爲止，我使用的是Windows服務實際執行公開WCF端點的任務以排隊新工作和管理現有任務。

我正在使用Entity Framework存儲所有作業的歷史記錄。然而，我並不完全知道應該如何建模執行作業的後臺進程（使用當前進度信息）和暴露此狀態的wcf服務之間的交互。

我應該完全分離這兩個部分，讓後臺進程定期將當前狀態寫入數據庫，WCF服務從那裏輪詢信息？

或者WCF服務直接從後臺進程獲取信息訪問靜態成員或類似的東西是否有意義？他們應該共享一個DataContext嗎？

我想擁有最新的信息，似乎有點奇怪，後臺處理和WCF服務都在同一進程中運行，但通過數據庫進行通信，但另一方面，它似乎是一個更好的建築...

非常感謝！

來源

2011-03-28 aKzenT

我會建議分離兩個部分。並將狀態保存在數據庫中，將來您還可以輕鬆地將架構擴展到多臺機器。您的數據庫和Web客戶端訪問可以停留在一臺服務器上，長時間運行的任務可以停留在多臺服務器上

碰撞一個不會影響其他。您將能夠正確記錄信息。審查信息，並準備報告執行時間和預測等可以產生如果狀態正確保存在數據庫中。

來源

2011-03-28 08:57:40

有道理。在這種情況下，你會如何推薦在後臺進程中使用DataContext？在服務運行期間保持打開狀態（週期性沖洗）似乎是一個糟糕的主意。所以相反，我會使用另一個線程，定期創建一個DataContext並更新數據庫？我使用SQLite作爲數據庫btw使服務易於部署。目前數據量不應該太高，但如果數據量變高，我可以選擇切換到SQL Server。 – aKzenT 2011-03-28 09:17:16

除非您的datacontext內存大小很大，否則您可以長時間保持上下文打開，上下文不會保持與服務器打開的連接，只有在加載或保存更改時，纔會從池中提取新連接以執行操作。長時間保持上下文環境會讓您更頻繁地進行更改，並且很少刷新它。 – 2011-03-28 15:05:27

一個很好的解決方案包括Web界面和工作人員之間的消息隊列（MSMQ，表格，無論什麼）。

Web界面對消息進行排隊並根據需要輪詢其狀態。工作人員（可能不止一個）選擇消息來處理它並更新狀態。

如果工作人員死機，消息應該返回隊列。

來源

2011-03-28 08:58:04

用於長時間運行的Windows服務的實體框架體系結構

回答

相關問題