Vb.net WCF数据对象最佳实践

我正在处理从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

公共接口IPublicApis
函数RetrieveQueryDataA（ByVal req作为请求A）作为响应A
函数RetrieveQueryDataB（ByVal req作为请求B）作为响应B
函数RetrieveQueryDataC（ByVal req作为请求C）作为响应C
端接口

根据建议，我首先为请求和响应对象创建了模式。然后，我使用SvcUtil创建生成的类，这样我就可以确保其他语言可以使用这些对象，并且客户机会发现模式易于使用（没有对其他模式的引用）。但是，由于请求和响应具有相似的数据，我希望使用接口和继承，这样我就不会实现同一代码的多个版本

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

---

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

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

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

因此，考虑到您显然可以控制模式（即，它们不是外部指定的），并且可以很好地利用WCF内置的数据契约功能，我很难看出您将从建议的方法中获得额外的复杂性和工作量

---

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

我接受了你的答案，因为对大多数人来说，这是正确的。在我的例子中，我认为我将继续进行对象转换，因为它只允许我对每种类型的请求执行一个开销任务的实现。