WCF和dto的大小

本文关键字：dto WCF | 更新日期: 2023-09-27 17:48:57

我们已经有了一个业务逻辑/数据访问层，我们通过一个WCF服务将其暴露在几个不同的端点上。我们已经创建了dto作为服务的数据契约。我们将通过不同的端点为多个不同的应用程序使用该服务。在一些应用程序中，我们只需要DTO的几个字段，而在其他应用程序中，我们可能需要几乎所有字段。对于那些我们只需要少量的对象，我们真的不想每次都"通过网络"发送整个对象——我们希望将其减少到给定应用程序实际需要的部分。

我在为每个应用程序创建特定的dto集(过度使用?)和在仅在某些应用程序中需要的成员上使用EmitDefaultValue=false之类的东西之间来回切换。我还考虑使用XmlSerializer而不是DataContractSerializer，以便更好地控制服务中的序列化。

我的问题是——首先，我们应该担心我们传递的数据的大小吗?其次，假设答案是"是"，或者即使答案是"否"，我们也决定关心它，这里建议采用哪种方法，为什么?

编辑

感谢到目前为止的回复。我担心我们可能会进入过早优化阶段。然而，我现在想让这个问题保持开放，希望我能得到一些答案，既为了我自己的启发，也以防其他人有这个问题，并且有正当的理由需要优化。

WCF和dto的大小

首先，我们应该担心我们传递的数据的大小吗?

您没有给出字段的数量/大小，但一般来说:No。您已经获得了信封和设置通道的开销，多几个字节不会有太大影响。

所以，除非我们讨论的是数百双精度或类似的东西，否则我会首先等待，如果真的有问题:实验和测量。

你应该担心吗?也许吧。性能/压力测试你的服务，找出答案。

如果你决定你真的在乎…几个选项:

  1. 创建一个不同的服务(或者可能是同一服务中的不同操作)，返回部分水合的DataContracts。因此，这些新的服务和/或操作返回相同的数据合约，但只是部分水合。

  2. 创建数据合约的"精简"版本，并返回这些版本。基本上与选项1相同，但是使用这种方法，您不必担心消费者滥用完整的DataContract(可能会得到空引用异常等)。

我更喜欢选项2，但如果你能控制你的消费者，选项1可能更适合你。

看来你可能进入了"过早优化"的区域。我将避免为实体使用特定于应用程序的datcontract，因为从长远来看，维护工作将导致问题。但是，如果您的应用程序确实需要对某些客户端应用程序隐藏信息，而不是对其他应用程序隐藏信息，那么为给定实体拥有多个datacontract是很好的。@Henk是对的，除非你处理的是大量深度嵌套的实体(在这种情况下你有一个不同的问题)，否则不要仅仅为了减少网络传输数据包而"优化"你的设计。

相关文章：