WCF：我应该如何在客户端和服务器中维护合同类？

Question

我正在使用服务器和客户端（自然地）处理WCF应用程序。在服务器项目中，我使用 contract 属性定义了类。

现在，当服务器准备就绪时，我添加了服务引用，它为我创建了代理。我用它，它确实工作正常。

我想问的问题是，如果我创建一个包含带有契约属性的类定义的公共DLL并将其用于服务器和客户端（而不是使用Visual Studio为客户端生成的类），那么可以。如果我使用公共类，我不必担心在自动代码生成时将泛型集合转换为数组。这很傻吗？可能吗？以前有人这样做过吗？这样做可以吗？

部署方案是安全内部网中的客户端数量有限（很少），并且只要服务器发生更改，就可以更新现有客户端。

Answer 1

这种方法很好（我使用了很多）只要你控制客户端。它（显然）不适用于Java客户端等。如果你知道你永远不需要支持非.NET客户端，那么它可能很强大，但它打破了一些纯粹的SOA规则。特别是，是的，Intranet场景是我可能会考虑这种方法的场景。

svcutil.exe和IDE都可以选择重复使用现有程序集中的类型来完成此操作。

编辑此方法的另一个优点是，如果您想在客户端使用相同的验证逻辑，而无需对其进行两次编码 - 例如IDataErrorInfo等。

Answer 2

如果您唯一关心的是没有将集合转换为数组，那么您不必走这么远。 “添加服务引用”对话框中的“高级”按钮允许您指定用于此类情况的类型。您可以使用List而不是T []。

Answer 3

在单独的通用程序集中维护合同类型是一个非常好的主意。例如，它使您有机会添加Adapters，以在这些类型之间转换合约类型和您可能拥有的其他业务对象或Mediators等。

即使您不控制所有客户端，使用常见类型也是有意义的。假设您拥有使用.NET的内部应用程序以及合作伙伴公司的可信第三方所使用的服务。合作伙伴应用程序使用Java，Ruby或Python。在这种情况下，合作伙伴将无法访问共享类型，但依赖于WSD / XSD，可以滚动自己的客户端类型库。这不应该妨碍你为你的内部开发者提供一个很好的共享类型包。

当您使用REST接口而不是WS / SOAP时，这种共享类型的建议也适用。使用REST，WSDL缺乏，但XSD（或类似）仍将用于描述服务器及其客户端交换的消息类型。因此，无论您使用SOAP还是REST，都无需更改建议。

编辑：而且，它适用于您使用.NET还是Java或其他任何东西。如果您控制电线的两端并且平台是相同的，那么是的，您应该共享类型。你为什么不呢？

Answer 4

创建单独的程序集以保存合同后，您可以引用这些程序集并使用它们从客户端为服务创建通道（使用ChannelFactory）。通过这样做，您不再需要在每次更改服务合同时更新“服务引用”。

ChannelFactory<IContract> factory = 
    new ChannelFactory<IContract>("endpointName");