我们正在使用的DTO在我们的WCF服务的接口，但是已经开始遇到问题时，业务对象的DTO再presents实现了超过一个单一的界面，我们希望返回的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.

举例来说，假设我们有一个接​​口 IBusinessObject 包含多个属性的对象之间的关系的细节，对象等等等等属性，我有几个实现这一个是一个 LinearBusinessObject 其中实施 IBusinessObject 和 ILinear 。有 ILinear 的其他实现这是不是也业务对象，只是简单的线性的事情。

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.

我们的服务有一个方法来获取业务对象。这返回一个基本DTO类（ BusinessObjectDto ）它声明的 IBusinessObject （关系属性等），共用部位和 LinearBusinessObjectDto 延伸 BusinessObjectDto ，并增加了对事物的线性边的额外信息。这是罚款，并可以使客户端处理返回的的BusinessObjects 有一定程度的多态性。

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.

我们也希望它得到一个线性的事情的方法。这将返回一个基类 LinearDto ，其中包含了常见的线性细节。简单的线性对象实现延长 LinearDto 键，一切都很好。但现在我有一个问题，因为我不能让我的 LinearBusinessObjectDto 来自 LinearDto 和和 BusinessObjectDto ，因为只有单继承的支持，我不能用接口，WCF不知道，然后把在服务合同定义的WDSL什么类型的。

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.

所以，我开始有2 DTOS我的 LinearBusinessObject ，其中之一源于 BusinessObjectDto （ LinearBusinessObjectAsBusinessObjectDto ）和其中一个源自LinearDto（ LinearBusinessObjectAsLinearDto ），然后将每一个基于我感兴趣的接口上。​​

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.

这似乎是它会产生很多额外的DTO类（其中我已经有很多），所以我不知道是否有比这更好的解决办法？还是这只是一些我们住在一起？

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.

在我看来，这是一个普遍的OO / SOA的问题，而不是一个特定的WCF问题：对青睐组成了继承旧的意见想到的。当涉及到服务，特别是，多态的设计不应该是你是什么后，你的DTO层。您应该避免使用DTO这么使用继承或接口（和接口都没有，甚至有可能，除非你序列化/动态deserialising ...你不能生成使用SvcUtil工具具体代理的具体类型是不知道在生成时，但是从我内存这是可能要在.NET客户端使用ChannelFactories的时候......我不记得，虽然细节）。

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).

在一般当你创建DTO / DataContracts只能定义为混凝土构件/属性在其中。你的DTO模式应该被设计成扁平和跨平台的，而不是面向对象的。

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.