在WCF服务及其.net客户端之间共享类型
在WCF服务及其.net客户端之间共享类型 虽然我知道这是可以做到的，但当您觉得需要在服务上使用程序集并在.net客户端上使用相同的程序集时，我不知何故觉得设计中存在一些根本错误 我需要这样做，因为我有一个数据契约，将在两个不同的服务中使用。当这两个服务在同一个客户端上被引用时，它们将导致相同的数据类型在两个不同的名称空间中可用。在我看来，当客户端使用它时，它会产生歧义的问题，或者至少看起来是多余的。另外，如果我共享这样的类型，这不是违背了提供服务的目的吗在WCF服务及其.net客户端之间共享类型,.net,wcf,.net,Wcf,在WCF服务及其.net客户端之间共享类型 虽然我知道这是可以做到的，但当您觉得需要在服务上使用程序集并在.net客户端上使用相同的程序集时，我不知何故觉得设计中存在一些根本错误 我需要这样做，因为我有一个数据契约，将在两个不同的服务中使用。当这两个服务在同一个客户端上被引用时，它们将导致相同的数据类型在两个不同的名称空间中可用。在我看来，当客户端使用它时，它会产生歧义的问题，或者至少看起来是多余的。另外，如果我共享这样的类型，这不是违背了提供服务的目的吗 对于像这样在服务和客户端之间共享类型，
对于像这样在服务和客户端之间共享类型，您有什么想法？这听起来像是糟糕的设计，会导致其他一些不可预见的问题吗。。。或者只是一般不寻常的设计 我这样做只是为了共享验证和构造函数逻辑。其他所有内容都属于服务器或客户端，因此我不想共享这些内容。我这样做只是为了共享验证和构造函数逻辑。其他所有内容都属于服务器或客户端，因此我不想共享这些内容。这取决于意图。如果服务的目的是在层之间有一个逻辑和/或物理边界，那么在边界的任意一侧使用相同的类型不会损害这一点，并且可以使一切工作更加方便。它还为您提供了一个要测试的单一类型模型等 当公开公共服务接口或跨平台可移植性存在问题时，mex/wsdl方法特别有用。但是，如果您不需要这些类型，那么重复使用这些类型（对或错）是非常诱人的。当一个应用程序通过一些私有API与不同节点上的同一个应用程序对话时，甚至可能会出现一个过于简化的版本——在这里引入一个单独的类型模型几乎没有什么好处。此外，共享类型可以提供一个更典型（更少代码生成愚蠢）的API，使用类型中执行验证的逻辑可以获得更丰富的验证
我会更多地从这项服务的“我需要/期望什么”着手；如果“它必须是跨平台的，并且独立于我的核心应用程序中的类型模型”不在列表中，则可能在出现时跨越该桥。这取决于意图。如果服务的目的是在层之间有一个逻辑和/或物理边界，那么在边界的任意一侧使用相同的类型不会损害这一点，并且可以使一切工作更加方便。它还为您提供了一个要测试的单一类型模型等 当公开公共服务接口或跨平台可移植性存在问题时，mex/wsdl方法特别有用。但是，如果您不需要这些类型，那么重复使用这些类型（对或错）是非常诱人的。当一个应用程序通过一些私有API与不同节点上的同一个应用程序对话时，甚至可能会出现一个过于简化的版本——在这里引入一个单独的类型模型几乎没有什么好处。此外，共享类型可以提供一个更典型（更少代码生成愚蠢）的API，使用类型中执行验证的逻辑可以获得更丰富的验证
我会更多地从这项服务的“我需要/期望什么”着手；如果列表中没有“它必须是跨平台的，并且独立于我的核心应用程序中的类型模型”，那么当它出现时，可能会跨越这座桥梁。服务/数据合同正是这个词所说的：合同。所有的要点是共享它-没有什么不对的，你应该把这些类型看作是同一合同的一部分（如果你喜欢的话，你可以和你的类型共享接口）。
显然，您可以始终采用wsdl的方式，并将其作为您的合同加上一堆定义您的类型的XSD来共享，但最终您将做完全相同的事情，只需再进一步，如果您知道您的客户机和服务都将是.NET，那么您实际上不需要这样做 服务/数据合同正是这个词所说的：合同。所有的要点是共享它-没有什么不对的，你应该把这些类型看作是同一合同的一部分（如果你喜欢的话，你可以和你的类型共享接口）。
显然，您可以始终采用wsdl的方式，并将其作为您的合同加上一堆定义您的类型的XSD来共享，但最终您将做完全相同的事情，只需再进一步，如果您知道您的客户机和服务都将是.NET，那么您实际上不需要这样做 这取决于使用场景。如果您不共享包含契约的程序集，那么您几乎是在强迫客户机通过使用服务引用创建服务代理，以及所有生成的代码。
如果您共享这些合同，您将可以更好地控制客户端代码。当中间层服务接口发生更改时，您也无需重新生成服务引用。这取决于使用场景。如果您不共享包含契约的程序集，那么您几乎是在强迫客户机通过使用服务引用创建服务代理，以及所有生成的代码。 如果您共享这些合同，您将可以更好地控制客户端代码。当中间层服务接口发生更改时，您也无需重新生成服务引用