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

Question

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

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

到目前為止，我正在使用Windows服務來實際執行將WCF端點公開給新工作排隊並管理現有任務的任務。

我正在使用實體框架存儲所有作業的歷史記錄。 但是，我不確定如何在執行作業的后台進程（具有當前進度信息）和公開此狀態的wcf服務之間建立交互模型。

我是否應該完全分開兩個部分，讓后台進程定期將當前狀態寫入數據庫，並且WCF服務從那里輪詢信息？

還是WCF服務從訪問靜態成員或類似對象的后台進程直接獲取信息有意義嗎？ 他們應該共享一個DataContext嗎？

我想要最新的信息，同時在后台運行后台處理程序和WCF服務，但是又通過數據庫進行通信，這似乎有些奇怪，但是另一方面，它似乎是一個更好的體系結構。 。

非常感謝！

Answer 1

我建議將這兩部分分開。 並將狀態保存在數據庫中，將來您還可以在其中輕松地將體系結構擴展到多台計算機。 您對數據庫和Web客戶端的訪問可以駐留在一台服務器上，而長時間運行的任務可以駐留在多台服務器上。

崩潰一個不會影響另一個。 您將能夠正確記錄信息。 查看信息並准備執行時間和預測時間的報告，如果狀態正確保存在數據庫中，則可以生成報告。

Answer 2

一個好的解決方案包括在Web界面和工作程序之間的消息隊列（MSMQ，表等）。

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

如果工作程序崩潰，則消息應返回隊列。