Question

我正处理从Web服务迁移到WCF的过程，而不是尝试在WCF中使旧代码工作，我只是要重建服务。作为这个过程的一部分，我还没有找到最好的设计来提供易于使用的服务，也支持未来的变化。

我的服务遵循以下模式;实际上我有更多的方法，所以重复代码是一个问题。

<ServiceContract()>
Public Interface IPublicApis

    <OperationContract(AsyncPattern:=False)>
    Function RetrieveQueryDataA(ByVal req As RequestA) As ResponseA

    <OperationContract(AsyncPattern:=False)>
    Function RetrieveQueryDataB(ByVal req As RequestB) As ResponseB

    <OperationContract(AsyncPattern:=False)>
    Function RetrieveQueryDataC(ByVal req As RequestC) As ResponseC

End Interface

遵循this建议，我首先为Request和Response对象创建了模式。然后我使用SvcUtil创建结果类，以便确保对象可以被其他语言使用，并且客户端将发现易于使用的模式（不引用其他模式）。但是，因为请求和响应具有类似的数据，所以我想使用接口和继承，这样我就不会实现相同代码的多个版本。

我考虑过在单独的类库中使用接口和继承来编写我自己的类版本，并在那里实现所有日志记录，安全性，数据检索逻辑。在每个操作中，我将只将RequestA转换为我的InternalRequestA并调用InternalRequestA的进程函数，该函数将返回InternalResponseA。然后我将其转换回ResponseA并发送给客户端。

这个想法是疯了吗？！？我在找到另一个在内部利用继承的解决方案时遇到了问题，但仍然为客户提供了支持未来更新的干净模式。

Answer 1

使用WCF数据合同创建的合同通常会生成相对直接的模式，这些模式具有高度的互操作性。我相信这是WCF设计的指导原则之一。但是，这种互操作性与消息本身有关，而与某些其他系统可能从中生成的对象无关。消息如何转换为另一端的对象/完全取决于另一个系统。

我们在使用数据合同对象的继承时没有遇到任何实际问题。

因此，鉴于您可以清楚地控制模式（即它们没有在外部指定）并且可以充分利用WCF的内置数据协定功能，我很难看到您将获得额外的复杂性和努力所带来的好处在你提出的方法中。

在我看来，与处理消息相关的逻辑应该与消息本身完全分开。

WCF数据对象最佳实践

1 个答案: