以前我们有桌面应用程序，但考虑到客户端不希望访问服务器(无论是物理还是远程)，我们将它们转变为将在(理论上)24/24小时运行的Windows服务 7.
现在我们需要为该服务提供一个远程用户界面，以保留旧的功能和旧的界面。
为此，我们考虑使用 WCF 开发多个 SOA 服务。我们将有一项服务用于配置，另一项服务用于例如网络信息、统计等，以便所有服务的总和提供与旧界面相同的功能，但分为不同的功能区域。
我在 SOA 方面没有太多经验，所以这个设计正确吗？ SOA 适合远程 UI 吗？应该只有一项服务还是应该有逻辑组？
注意:我们有多个应用程序可以访问服务上的部分信息，这就是我们进行这种逻辑划分的原因。
编辑:是否值得对谁可以连接以及什么可以尽早访问实现任何安全措施？我看到它时带有一个很大的 YAGNI 警告，但也许我错了。
我对有关如何实现远程 UI、现有框架、最佳方法、使用 SOA 的优点和缺点等的各种建议感兴趣
最佳答案
当您说“远程 UI”时，我认为您实际上是指您有一些在远程服务器上执行的操作，但通过 API 远程调用。
远程 UI 意味着用户界面正在服务计算机上运行，并且用户通过投影的 UI 与服务交互，例如诸如终端服务之类的东西。
在 SOA api 中公开服务所做的工作可能是您想要采取的最佳途径。然后，您可以在 Winforms、Silverlight、ASP.Net 或将来的任何其他内容中实现 UI。 SOA 对于很多人来说意味着很多事情，但我喜欢将其视为系统中的边界点，其中各方都不了解对方的实现细节。
决定服务的粒度并不总是显而易见的，但如果您尝试考虑为服务使用者提供的功能，而不仅仅是您目前负责实现的 UI 应用程序。这些事情当然不是一成不变的，您可以随着事情的进展进行重构。单个应用程序可以使用多个服务，因此在这方面不存在问题。
在我工作的地方，我们通常先实现功能，然后再回答安全问题。您的安全要求当然是特定的，但您需要考虑诸如所访问数据的敏感性或用户可以通过服务调用的功能等因素。该服务是否在您的网络内部使用或通过互联网公开，以及用户尝试进行恶意行为的可能性。例如，业务用户不太可能下载 Visual Studio 的副本并创建自己的 WCF 客户端以造成严重破坏，但一切皆有可能。
关于.net - 远程 UI 是否应该使用 SOA 来实现？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1359583/