用于长时间运行的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服务的实体框架体系结构

回答

相关问题