定义一个dto对象,如何处理的DTO为其实现多个接口的对象？

We are using Dtos in our WCF service interface, but have started to come across issues when the Business Object that the Dto represents implements more than a single interface and we want to return the Dtos in those different contexts and to also be able to treat the Dtos polymorphically on the client.

For example lets say we have an interface for an IBusinessObject with several properties containing details of the relationships of the object, attributes of the object etc etc. I have several implementations of this one being a LinearBusinessObject which implement IBusinessObject and ILinear. There are other implementations of ILinear which are not also business objects, just simple linear things.

Our service has a method to get a business object. This returns a base Dto class (BusinessObjectDto) which declares the common parts of a IBusinessObject (relationships attributes etc) and the LinearBusinessObjectDto which extends BusinessObjectDto and adds the extra information about the linear side of things. This is fine and enables the client to treat the returned BusinessObjects with some degree of polymorphism.

We also want a method which gets a Linear thing. This returns a base class LinearDto which contains the common linear details. The simple linear object implementation extend LinearDto and all is good. But now I have a problem, as I can't have my LinearBusinessObjectDtoextend from both LinearDto and and BusinessObjectDto as only single inheritance is supported, and I can't use interfaces as WCF doesn't know what types to then put in the service contract definitions in the WDSL.

So I've started having 2 dtos for my LinearBusinessObject, one which derives from BusinessObjectDto (LinearBusinessObjectAsBusinessObjectDto) and one which derives from LinearDto (LinearBusinessObjectAsLinearDto) and then converting each one based on the interface I'm interested in.

This seems like its going to result in many extra Dto classes (of which I already have many) and so I'm wondering if there is a better solution than this? Or is this just something we have to live with?

解决方案

A wise man once told me that Object Orientation is the enemy of services.

It seems to me that this is a general OO/SOA problem rather than a specific WCF problem: the old advice of "Favor Composition over Inheritance" comes to mind. When it comes to services especially, Polymorphic designs should not be what you are after in your DTO layer. You should avoid using DTO's that use inheritance or Interfaces (and interfaces are not even possible unless you are serializing/deserialising dynamically...you can't generate concrete proxies using SVCUtil as the concrete types are not known at generation time, but from my memory this is possible when using ChannelFactories in your .NET client...I can't remember the details though).

In general when you create DTO/DataContracts only define members/properties in them that are concrete. Your DTO model should be designed to be flat and cross platform, not Object Orientated.