长时间运行Windows服务的实体框架体系结构

Question

我有一个问题，如何在Windows服务中使用实体框架来最好地构建我的解决方案。

我想提供一个在线（web）服务，允许用户执行可能长时间运行的任务，观察任务的进度，取消任务等。

到目前为止，我正在使用Windows服务来实际执行将WCF端点公开给新工作排队并管理现有任务的任务。

我正在使用实体框架存储所有作业的历史记录。 但是，我不确定如何在执行作业的后台进程（具有当前进度信息）和公开此状态的wcf服务之间建立交互模型。

我是否应该完全分开两个部分，让后台进程定期将当前状态写入数据库，并且WCF服务从那里轮询信息？

还是WCF服务从访问静态成员或类似对象的后台进程直接获取信息有意义吗？ 他们应该共享一个DataContext吗？

我想要最新的信息，同时在后台运行后台处理程序和WCF服务，但是又通过数据库进行通信，这似乎有些奇怪，但是另一方面，它似乎是一个更好的体系结构。 。

非常感谢！

Answer 1

我建议将这两部分分开。 并将状态保存在数据库中，将来您还可以在其中轻松地将体系结构扩展到多台计算机。 您对数据库和Web客户端的访问可以驻留在一台服务器上，而长时间运行的任务可以驻留在多台服务器上。

崩溃一个不会影响另一个。 您将能够正确记录信息。 查看信息并准备执行时间和预测时间的报告，如果状态正确保存在数据库中，则可以生成报告。

Answer 2

一个好的解决方案包括在Web界面和工作程序之间的消息队列（MSMQ，表等）。

Web界面将消息排队，并根据需要轮询其状态。 工作人员（可能不止一个）选择消息进行处理并更新状态。

如果工作程序崩溃，则消息应返回队列。