在WCF服务与其.net客户端之间共享类型
虽然我知道可以做到这一点，但是当我觉得需要在服务上使用程序集并在.net客户端上使用相同的程序时，我会觉得设计中存在根本性的错误。
我需要这样做，因为我有一个将在两个不同服务中使用的数据协定。当这两个服务在同一客户端上引用时，它们将导致在两个不同的名称空间中可用的相同数据类型。对我来说，这似乎会在客户端使用时产生歧义问题，或者至少看起来多余。另外，如果我分享这样的类型，它不会破坏提供服务的目的吗？
您对服务与客户之间的共享类型有何看法？这听起来像是糟糕的设计，以后会导致其他一些不可预见的问题吗？ ......或者一般只是不寻常的设计！
答案 0 :(得分：4)
Service / DataContract正是这个词所说的：合同。重点是分享它 - 没有任何问题，您应该将类型视为同一合同的一部分（如果您愿意，您可以只与您的类型共享接口）。
显然你总是可以按照wsdl的方式分享它作为你的合同加上一堆定义你的类型的xsds，但最后你正在做完全相同的事情，只需要一步此外，如果您知道您的客户端和服务都是.NET，那么您根本不需要。
答案 1 :(得分：3)
这取决于意图。如果您的服务的目的是在层之间具有逻辑和/或物理边界，那么在边界的任一侧使用相同类型不会对其造成任何伤害，并且可以使一切工作更方便。它还为您提供了一个单一的模型来测试等。
mex / wsdl方法在公开 public 服务接口或跨平台可移植性存在问题时特别有用。但是如果你不需要它，重复使用这些类型可能非常诱人（对或错）。这个过度简化的版本甚至可以在应用程序通过某个私有API与不同节点上的同一个应用程序进行通信时 - 这里引入一个单独的类型模型几乎没有增加。此外，共享类型可以提供更典型（更少代码生成）的API，并且通过类型中的逻辑执行验证，您可以获得更丰富的验证。
我会从这项服务的“我需要/期待什么”中接近这一点;如果“它必须是跨平台的，并且独立于我的核心应用程序中的类型模型”不在列表中，那么如果/何时出现，可能会越过该桥。
答案 2 :(得分：1)
我只是这样做来共享验证和构造函数逻辑。其他所有东西都属于服务器或客户端，所以我不想分享它。
答案 3 :(得分：0)
这取决于使用场景。如果您不共享包含合同的程序集，那么您几乎强迫客户端使用服务引用创建服务代理 - 以及所需的所有生成代码。 如果您共享合同，您将可以更好地控制客户端代码。每当中间层服务接口发生变化时，您也无需重新生成服务引用。