在 WCF 服务及其 .net 客户端之间共享类型

Posted 2023-03-07

【中文标题】在 WCF 服务及其 .net 客户端之间共享类型

【英文标题】：Sharing types between WCF services and their .net clients

【发布时间】：2011-06-24 18:24:38

【问题描述】：

WCF 服务与其 .net 客户端之间的共享类型

虽然我知道可以做到这一点，但当您觉得需要在服务上使用程序集并在 .net 客户端上使用相同的程序集时，我不知何故觉得设计中存在根本性错误。

我需要这样做，因为我有一个将用于两个不同服务的数据合同。当在同一个客户端上引用这两个服务时，它们将导致相同的数据类型在两个不同的命名空间中可用。在我看来，这在客户使用时会产生歧义问题，或者至少看起来是多余的。另外，如果我共享这样的类型，它不会违背提供服务的目的吗？

您对像这样在服务和客户端之间共享类型有何看法？这听起来像是糟糕的设计，会在以后导致一些其他无法预料的问题吗？ ...或者只是不寻常的设计！

【参考方案1】：

Service/DataContract 正是这个词所说的：合同。重点是共享它——这没有错，您应该将类​​型视为同一个 Contract 的一部分（如果您愿意，您可以只共享类型的接口）。

显然，您始终可以采用 wsdl 方式并将其共享为您的合同以及定义您的类型的一堆 xsd，但最终您正在做完全相同的事情，只需一步此外，如果您知道您的客户端和服务都将是 .NET，那么您实际上并不需要这样做。

【参考方案2】：

这取决于意图。如果您的服务的目的是在层之间具有逻辑和/或物理边界，那么在边界的任一侧使用相同的类型不会有任何损害，并且可以使一切工作更方便。它还为您提供了一个单一类型的模型来测试等。

mex/wsdl 方法在公开 public 服务接口或跨平台可移植性存在问题时特别有用。但是，如果您不需要它，那么重用这些类型可能非常诱人（对或错）。当一个应用程序通过一些私有 API 与不同节点上的同一个应用程序对话时，这种过度简化的版本甚至可能——在这里引入一个单独的类型模型几乎没有什么作用。此外，共享类型可以提供更典型的（更少的代码生成愚蠢）API，并且使用类型中的逻辑来执行验证，您可以获得更丰富的验证。

我会更多地从这项服务的“我需要/期望什么”来解决这个问题；如果“它必须是跨平台的并且独立于我的核心应用程序中的类型模型”不在列表中，那么如果/当它出现时，可能会跨越那座桥。

【参考方案3】：

我这样做只是为了共享验证和构造函数逻辑。其他一切都属于服务器或客户端，所以我不想分享。

【参考方案4】：

这取决于使用场景。如果您不共享包含合同的程序集，您几乎是在强迫客户端通过使用服务引用来创建服务代理 - 以及所需的所有生成代码。 如果您共享合同，您将可以更好地控制您的客户端代码。您还无需在中间层服务接口发生变化时重新生成服务引用。