WCF数据对象最佳实践

我正在从Web服务迁移到WCF，而不是试图让旧的代码在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并发送给客户端。

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

来源

2011-03-24 Zach Green

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

对于使用数据约定对象的继承，我们没有真正的问题。因此，考虑到你明确控制了模式（即它们没有在外部指定），并且可以很好地利用WCF的内置数据合同功能，所以我很难看到你将获得额外的复杂性和工作量的好处暗示在你提出的方法中。

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

来源

2011-03-25 01:08:26

我接受了你的答案，因为对大多数人来说它是正确的。在我的情况下，我想我会继续进行对象转换，因为它允许我只需要执行一次执行的开销任务，而且必须执行每种类型的请求。 – 2011-03-28 17:09:19

WCF数据对象最佳实践

回答

相关问题