WCF 对象设计 - OOP 与 SOA答案

【问题标题】：WCF Object Design - OOP vs SOAWCF 对象设计 - OOP 与 SOA
【发布时间】：2011-01-02 15:24:06
【问题描述】：

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

在我看来，SOA 和 OOP 相互矛盾 - 要公开一个干净的 WSDL，您需要具体的对象，通常甚至不使用继承。另一方面，大概在底层系统中，您会希望遵循正确的 OO 设计。

人们通常在这里做什么？构建一组 WCF 合约对象，放弃 OOP 原则，然后在实际逻辑层中转换为另一组对象？

【问题讨论】：

标签： wcf design-patterns oop soa

【解决方案1】：

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

将 WCF 合同/SOAP 消息视为服务用于通信的简单消息（不要将其与代码中的对象紧密绑定）。

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

【讨论】：

【解决方案2】：

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

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

一般来说，如果您发现您正在获取具有依赖关系的业务对象，您应该考虑将此类依赖关系拉到服务业务层，而不是将依赖关系注入业务对象。然后，服务业务层将充当中介者，作用于 WCF 服务代理和业务对象。与让业务对象作用于 WCF 服务代理相反。

【讨论】：

【解决方案3】：

人们通常在这里做什么？构建一组 WCF 合约对象，放弃 OOP 原则，然后在实际逻辑层中转换为另一组对象？

是的。

WCF 对事物进行序列化的方式最终对合同对象可以做什么和不可以做什么施加了很多限制。你不能做的事情最终会变成“最有用的东西”。

我发现，如果您将 WCF 合同对象仅视为一种数据传输机制，事情就会变得更加清晰。基本上就像强/静态类型的 XML。
您无需将业务对象转换为 XML 字符串（然后再转换回来），而是将业务对象转换为 WCF 合同对象（然后再转换回来），但在其他方面类似

【讨论】：

那么您会添加一个.ToWCFDataContract() 方法和一个接受您的WCFDataContract 对象到您的业务对象的构造函数吗？
非常感谢。想到我必须创建另一组对象有点令人沮丧（至少可以说这不是一个小服务），但现在我知道没有更好的选择，我不会觉得我我在浪费时间。

【解决方案4】：

关于这个主题的所有伟大的cmet！我将对在面向服务和面向对象之间进行调解的适配器的概念投赞成票。我也喜欢 Thomas Erl 的方法，他在他的服务模型中引入了“应用程序服务”和“业务服务”的概念。这些是您与特定应用程序/业务环境（即面向对象和面向组件的框架/API）的集成点的方法。对于您的企业框架专家来说，这种方式应该会带来更好的可组合性和能力。

【讨论】：