在WCF / SOAP世界中处理多态业务对象的正确方法是什么？

在我看来，SOA和OOP彼此矛盾-要暴露干净的WSDL，您需要具体的对象，通常甚至不利用继承。 另一方面，大概在底层系统中，您将需要遵循正确的OO设计。

人们通常在这里做什么？ 建立一组WCF合同对象，放弃OOP原则，然后在实际逻辑层中与另一组对象进行相互转换？

What do people typically do here? Build a set of WCF contract objects, forgoing OOP principles, then convert to and from another set of objects in the actual logic layers?

是。

WCF序列化事物的方式最终使合同对象可以做什么和不能做什么都受到很多限制。您无法做的事情最终变成了"最有用的东西"。

如果您将WCF合同对象视为数据传输机制，我发现它使事情变得更加清晰。基本上就像强/静态类型的XML。
无需将业务对象转换为XML字符串(并再次转换)，而是将业务对象转换为WCF合同对象(并再次转换)，但是在其他方面相似

阅读了Thomas Erl库之后，我得出以下结论：

可以将WCF合同/ SOAP消息视为服务用于通信的消息(不要将其与代码中的对象紧密关联)。

然后，您可以使用OOP设计代码库，从而使用常见的OOP技术优雅地处理这些消息。

关于此主题的所有精彩评论！我将投票支持适配器的概念，以在您的服务方向和对象方向之间进行中介。我也喜欢Thomas Erl的方法，他在他的服务模型中引入了"应用程序服务"和"业务服务"的概念。这些是与特定应用程序/业务环境(即面向对象和面向组件的框架/ API)集成点的方法。对于您的企业框架专家来说，这种方式应该导致更好的可组合性和功能。

您可以使用带有WCF属性注释的抽象(接口类型)来定义您的服务合同。

这既取决于根据OOP进行的抽象，又取决于定义服务端点即SOA。

通常，如果发现要获取具有依赖项的业务对象，则应考虑将此类依赖项上移到服务业务层，而不是将依赖项注入到业务对象中。
然后，服务业务层将充当充当WCF服务代理以及业务对象的中介者。与使业务对象在WCF服务代理上起作用相反。