带有工作线程的 WCF 服务 - 如何设计？答案

【问题标题】：WCF Service with Worker Thread - how to design?带有工作线程的 WCF 服务 - 如何设计？
【发布时间】：2012-04-20 01:01:36
【问题描述】：

我有一个为一些客户提供服务的 WCF 服务。设计是：

WCF 服务层
业务逻辑层
数据访问层（LINQ-To-Entities）

我需要有一个工作线程在数据库上执行一些连续工作（查找新记录，如果发现任何记录 - 以“推送”方式向客户端发送信息，这意味着 - 客户端将托管服务所以它可以从这个工作线程接收“推送”通知）。

我将在 Windows 服务上托管 WCF 服务。

问题是：在我的设计中，我应该在哪里安装这个工作线程？它是否应该与 WCF 服务一起在 Windows 服务的“Program.cs”的“Main()”中生成？（这意味着它应该是 WCF 服务程序集的一部分）或者它应该是业务逻辑层的一部分 - 因此是“业务逻辑”组件的一部分？

我的想法：

【问题讨论】：

您能否澄清“客户将托管服务”的含义？您是说 WCF 服务必须了解所有客户端吗？推送是必需的吗？您能控制客户吗？
我会在最顶层生成它，所以在 Main() 中
“推送”是一项要求。当客户端连接到服务器时，它会将它的端点配置传递给服务器，服务器也将作为客户端连接到客户端。这样服务器就可以向客户端推送信息（CallBack 支持对我没有好处，因为服务器无法发起自己对客户端的调用）...

标签： wcf worker-thread

【解决方案1】：

为什么它需要成为任一程序集的一部分？我会完全在它自己的进程中托管这个工作线程。例如，将其托管在单独的 Windows 服务中。

然后它可以轮询数据库并将数据推送到客户端。

更新

您的设计将三种不同的操作结合在一起。首先你有数据库读取操作。然后你有数据库更新操作。然后你有数据库通知（或事件）。

这些不同类型的操作要求中的每一个都应该相互分离。这使得整个架构更易于维护和理解。

例如，通过解耦读取操作，您可以决定是否使用服务接口。也许可以让您的客户端使用 ADO 直接连接数据库以执行选择操作？

无论如何，无论您是否使用服务，更新操作都应该离线。没有充分的理由将读写操作耦合在一起。这也允许您减少数据库争用的可能性，并再次保持一切简单。客户端向更新队列发送异步更新命令，然后更新服务更新数据库。

这就是我的想法：

【讨论】：

嗯，这是我想到的想法的图像："What I Had In Mind"。该工作线程需要知道哪些客户端连接到 WCF 服务，因此它可以连接到它们并向它们发送 PUSH 消息（每个客户端也将托管它自己的 WCF 服务）。这样，工作线程也可以使用 WCF 服务的数据访问层，而不是创建自己的 DAL。这是错的吗？
那么为什么不在数据库中保留客户端端点列表呢？更好的是，让每个客户端都订阅来自数据推送服务的更新。
首先 - 你用什么工具来制作这张很酷的图画？？其次 - 我认为来自客户端的更新需要是即时的，而不是离线的。所以我不希望客户按下按钮来更新一些信息，他们刷新屏幕（读取）并看到信息尚未更新。他不明白为什么信息还没有更新（这无助于向他解释更新在离线队列中）。客户希望立即看到信息更新。我认为如果我使用“事务范围”，它应该可以防止我可能遇到的任何并发问题。
再说一次 - 我想我会将“读取”和“写入”操作留在同一个服务中，而“写入”操作包含在事务范围中（95% 的时间客户只会读取数据）。关于通知-您是否建议客户端连接到“读+写”的一项服务和“通知订阅”的另一项服务？我担心“通知服务”将发送的信息与其他服务所做的“读+写”不一致，这就是为什么我认为它们应该在同一个服务中，使用锁\事务范围。
图表是在 Balsamiq (balsamiq.com/products/mockups) 中完成的。很高兴你觉得它看起来很酷。它实际上是用于线框图，但我用它来做所有事情。