我们在我们的 WCF 服务接口(interface)中使用 Dtos，但是当 Dto 代表的业务对象实现多个接口(interface)并且我们希望在这些不同的上下文中返回 Dtos 并且还能够在客户端以多态方式处理 Dto。
例如，假设我们有一个 IBusinessObject 的接口(interface)有几个属性包含对象关系的详细信息，对象的属性等。我有这个的几个实现是LinearBusinessObject哪个实现IBusinessObject和 ILinear . ILinear还有其他实现这也不是业务对象，只是简单的线性事物。
我们的服务有一个获取业务对象的方法。这将返回一个基 Dto 类 ( BusinessObjectDto )，它声明了 IBusinessObject 的公共(public)部分。 (关系属性等)和 LinearBusinessObjectDto延伸 BusinessObjectDto并添加有关事物线性方面的额外信息。这很好，使客户端能够处理返回的 BusinessObjects具有一定程度的多态性。
我们还想要一个获取线性对象的方法。这将返回一个基类 LinearDto其中包含常见的线性细节。简单的线性对象实现扩展 LinearDto一切都很好。但是现在我有一个问题，因为我不能拥有我的 LinearBusinessObjectDto从 LinearDto 延伸和 BusinessObjectDto因为只支持单一继承，而且我不能使用接口(interface)，因为 WCF 不知道然后将什么类型放入 WDSL 的服务契约定义中。
所以我开始为我的 LinearBusinessObject 设置 2 个 dto , 一个派生自 BusinessObjectDto ( LinearBusinessObjectAsBusinessObjectDto ) 和派生自 LinearDto 的一个 ( LinearBusinessObjectAsLinearDto )，然后根据我感兴趣的接口(interface)转换每一个。
这似乎会产生许多额外的 Dto 类(我已经有很多)，所以我想知道是否有比这更好的解决方案？或者这只是我们必须忍受的东西？
最佳答案
一位智者曾经告诉我，面向对象是服务的敌人。
在我看来，这是一个普遍的 OO/SOA 问题，而不是一个特定的 WCF 问题:我想到了“优先考虑继承优先于组合”的老建议。特别是在服务方面，多态设计不应该是您在 DTO 层中所追求的。您应该避免使用使用继承或接口(interface)的 DTO(除非您动态序列化/反序列化，否则接口(interface)甚至是不可能的......您不能使用 SVCUtil 生成具体代理，因为具体类型在生成时未知，但从我内存 这在您的 .NET 客户端中使用 ChannelFactories 时是可能的...不过我不记得细节了)。
通常，当您创建 DTO/DataContracts 时，只在其中定义具体的成员/属性。您的 DTO 模型应该设计为扁平的和跨平台的，而不是面向对象的。
关于c# - 如何处理实现多个接口(interface)的对象的 Dtos？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9599079/