WCF对象设计 - OOP vs SOA

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

在我看来，SOA和OOP是在相互争执 - 以露出清洁WSDL你需要具体的对象，通常甚至没有利用继承。另一方面，大概在底层系统中，您将需要遵循适当的OO设计。

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

来源

2010-01-07 mdryden

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

是的。

WCF序列化的东西最终造成了很大的限制上，你可以和不能与合同对象做什么的方式。你做不到的事情最终会变成“最有用的东西”。

我发现它使事情，如果你认为WCF的合同的更清晰的对象只是一个数据传输机制。基本上像强/静态类型的XML。
而不是你的业务对象转换为XML字符串（和回来），你转换业务对象的WCF合同对象（和回来），但它在这个题目，否则类似

来源

2010-01-07 20:04:47

所以你会添加一个'.ToWCFDataContract（）'方法和一个接受你的WCFDataContract对象到你的业务对象的构造函数？ – Nate 2010-01-07 20:21:23

非常感谢。想到我必须创建另一组对象（这不是一个小服务，至少可以说），这有点令人沮丧，但现在我知道在那里没有更好的选择，我不会感觉到就像我在浪费时间。 – mdryden 2010-01-07 20:54:21

@Nate：非常好，是的 – 2010-01-08 02:06:02

阅读托马斯·尔库后，我来到了以下结论：

的WCF合同/ SOAP消息作为一个简单的消息认为，服务用于通信（不扎紧，要在对象你的代码）。

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

来源

2010-01-07 19:31:57

您使用一个抽象（接口类型）注释与WCF属性为了定义您的服务合同。

这既取决于抽象，其根据OOP，以及定义一个服务端点，这是SOA。

一般来说，如果你发现你用的依赖性越来越业务对象，你应该考虑拉这种依赖到服务业务层，而不是依赖注入的业务对象。然后，服务业务层将充当一个调解器，既作用于WCF服务代理也作用于业务对象。而不是让业务对象作用于WCF服务代理。

来源

2010-01-07 19:43:54 Tormod

所有伟大的评论！我会将我的投票添加到您的服务方向和面向对象之间的调解适配器的概念。我也喜欢Thomas Erl的方法，在他的服务模式中他介绍了“应用程序服务”和“商业服务”的概念。这些是您的特定应用程序/业务环境（即面向对象和面向组件的框架/ API）的集成点。这种方式应该为您的企业框架大师带来更好的可组合性和能力。

来源

2010-06-02 17:03:50 Timex

WCF对象设计 - OOP vs SOA

回答

相关问题