如何在.NET中设计这个客户端/服务器应用程序的架构？

Question

如何在.NET中设计这个客户端/服务器应用程序的架构？

5

我们有一个遗留的第三方工具（使用C/C++开发）。该工具具有运行Windows服务器的服务器组件，该服务器运行作业（复杂链式长数据库查询）。它还具有客户端模块，安装在所有用户桌面上，用户可以添加作业、查看正在运行的作业及其进度、删除作业，即基本管理作业。我们想使用.NET技术在内部开发这样的工具。

目前，我们正在考虑如何设计这样的工具，似乎我们缺少一些关键的拼图。

客户端：我们决定使用WPF开发客户端桌面应用程序。

服务器：目前，我们考虑将其开发为控制台应用程序，但不确定如何设计它。

我们主要的问题是：

1. 服务器控制台应用程序如何公开ASMX或WCF Web服务（以便WPF客户端获取作业状态），同时继续运行作业？

2. 当有变化时，如何从服务器向WPF客户端推送进度更新？

我们正在研究如何做到这一点，但没有找到与该主题相关的任何内容。任何指向文章/指导的指针都将非常有帮助。

- Aron

可能重复：http://stackoverflow.com/questions/11170457/discussion-client-server-application-architecture。 - Heretic Monkey

@MikeMcCaughan，你提到的链接虽然看起来相似，但在我的情况下并不是这样。我的服务器除了为客户提供服务外，还有一个长时间运行的工作要做。 - Aron

试试这个：http://dasunhegoda.com/architecture-products/1180/ - Techie

2个回答

1

听起来你在询问关于 WCF 服务的托管选项。这里有四个选项：

在托管应用程序中自主托管 - 即创建一个控制台应用程序、另一个 WPF 应用程序等，然后创建一个服务并在其（控制台应用程序）运行时保持其活动状态。
托管 Windows 服务 - 创建一个 Windows 服务，可以在 Windows 启动时自动启动
Internet Information Services (IIS) - 将其类似于 ASP.NET 服务进行托管
Windows 进程激活服务 (WAS) - 新的激活服务，我个人没有使用过。

完整详情请参见此处。

为了完全回答你的问题，我不会使用 ASMX 服务。有关原因的详细列表，请参见此问题。

- vlad

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Phil Patterson · Accepted Answer

你的困惑在于认为作业的执行和WCF端点是同一件事情。我会将其分成三个主要部分:

1.客户端应用程序，具有作业管理的UI元素。 2.用于检索作业信息并发送创建/删除作业请求的WCF服务端点。 3.运行作业的应用程序。

客户端应用程序应通过WCF服务检索作业数据。您将提供屏幕来查看正在执行的作业/创建作业/删除作业等。

WCF服务将公开客户端应用程序所需的端点。这可能包括：CreateJob、ViewJobs、DeleteJob等。该服务应从数据库后端读取/写入。

作业应用程序将轮询新建/已删除的作业，并执行完成作业所需的任何操作。它将更新数据库后端中WCF服务读取的作业状态。可能是SQL作业、Windows服务、控制台应用程序等（因为您可能需要始终运行以处理作业，所以我可能会将其设置为Windows服务）。

如何使服务器控制台应用程序同时发布ASMX或WCF Web服务（以便WPF客户端获取作业状态）而不中断作业运行？

通过将WCF服务与运行作业的应用程序分离，可以消除这种影响。请注意：您可以有一个托管WCF和作业执行器的控制台应用程序，但在概念上将它们视为不同的事物（在同一个控制台应用程序中托管只是一种实现细节）。

如何在服务器和WPF客户端之间进行状态更改时推送进度更新？

我不会这样做。我会让用户界面（UI）定期轮询相应的WCF端点来检索状态，或提供一个刷新按钮。如果您一定需要这样做，则需要作业执行器在运行作业时发布出消息，客户端应用程序需要接收这些消息（可能使用MSMQ、Service Bus实现、BizTalk等）。

为什么我更喜欢轮询而不是服务器推送？

现在我想起来，可能有一些情况我会选择推送模式，也可能有一些情况我会选择轮询。

如果我有许多远程客户端（通过VPN连接或通过互联网连接），则由于带宽和网络延迟成本过高，我会让客户端定期轮询。如果客户端数量很多，则每个更新消息都需要发送到每个订阅客户端。在这种情况下，我倾向于采用“问而非告诉”的模型（ask don't tell）。

如果客户在公司内部，而您需要向他们实时提供信息，则推送模型可能更合适。在这种情况下，您可以让客户端连接到服务器应用程序，然后他们可以通过连接互相发送信息（我个人没有做过这个，所以我对如何设置没有建议，希望有比套接字更高级的方法）。

如果需要在消息更新时将消息作为更新传递给客户端，但客户端位于不同的位置，则发布/订阅模型可能是最好的选择。在发布/订阅中，应用程序将随着事件的发生推送更新消息。消息系统将检查是否有任何客户端正在订阅消息，并且对于所有订阅消息的客户端，消息系统都会将消息的副本转发给他们。在您的示例中，客户端将“订阅”作业消息，消息系统将向客户端指定的位置发送更新（客户端需要一种接受消息的方式）。NServiceBus、BizTalk是此类通信的示例。