我们在 WCF 服务接口中使用 Dtos，但当 Dto 表示的业务对象实现多个接口时，我们开始遇到问题，并且我们希望在这些不同的上下文中返回 Dtos，并且还能够处理Dtos 在客户端上是多态的。
例如，假设我们有一个接口IBusinessObject有几个属性，其中包含对象关系的详细信息、对象的属性等。我有几个实现，这是一个LinearBusinessObject哪个实施IBusinessObject and ILinear。还有其他的实现ILinear它们也不是业务对象，只是简单的线性事物。
我们的服务有一个获取业务对象的方法。这将返回一个基 Dto 类 (BusinessObjectDto) 声明了 a 的公共部分IBusinessObject（关系属性等）和LinearBusinessObjectDto这延伸了BusinessObjectDto并添加有关事物线性方面的额外信息。这很好，并且使客户端能够处理返回的BusinessObjects具有一定程度的多态性。
我们还想要一个获得线性事物的方法。这将返回一个基类LinearDto其中包含常见的线性细节。简单的线性对象实现扩展LinearDto一切都很好。但现在我有一个问题，因为我不能拥有我的LinearBusinessObjectDto从两者延伸LinearDto和和BusinessObjectDto因为仅支持单一继承，并且我无法使用接口，因为 WCF 不知道要在 WDSL 中的服务契约定义中放入什么类型。
所以我开始为我的 2 个 dtosLinearBusinessObject，一个源自BusinessObjectDto (LinearBusinessObjectAsBusinessObjectDto) 和一个派生自 LinearDto (LinearBusinessObjectAsLinearDto），然后根据我感兴趣的界面转换每一个。
这似乎会导致许多额外的 Dto 类（我已经有很多），所以我想知道是否有比这更好的解决方案？或者这只是我们必须忍受的事情？
一位智者曾经告诉我，面向对象是服务的敌人。
在我看来，这是一个一般的 OO/SOA 问题，而不是一个特定的 WCF 问题：我想起了“优先考虑组合而不是继承”的旧建议。特别是当涉及到服务时，多态设计不应该是您在 DTO 层中所追求的。您应该避免使用使用继承或接口的 DTO（并且接口甚至是不可能的，除非您动态序列化/反序列化...您无法使用 SVCUtil 生成具体代理，因为具体类型在生成时未知，但从我的内存，在 .NET 客户端中使用 ChannelFactories 时这是可能的......但我不记得细节了）。
一般来说，当您创建 DTO/DataContracts 时，仅在其中定义具体的成员/属性。您的 DTO 模型应该设计为扁平且跨平台的，而不是面向对象的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
