5

我正在开发一个带有服务器和客户端的 WCF 应用程序（自然）。在服务器项目中，我定义了具有合同属性的类。

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

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

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

4

4 回答 4

2

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

svcutil.exe 和 IDE 都可以选择重用现有程序集中的类型来完全做到这一点。

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

于 2009-03-21T12:41:12.743 回答
2

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

于 2009-03-21T13:07:36.287 回答
2

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

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

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

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

于 2009-03-31T20:58:52.187 回答
1

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

ChannelFactory<IContract> factory = 
    new ChannelFactory<IContract>("endpointName");
于 2009-03-31T21:18:35.587 回答