WCF对象设计 - OOP vs SOA [英] WCF Object Design - OOP vs SOA

问题描述

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

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

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

解决方案

blockquote>

人们通常在这里做什么？构建一组WCF契约对象，执行OOP原则，然后转换到实际逻辑层中的另一组对象？

是的。

WCF序列化事情的方式最终会对您可以和无法对合同对象做很多限制。您不能做的最终是最有用的。

如果您将WCF合约对象视为只是，我发现它使事情变得更加清晰数据传输机制。基本上像强/静态类型的XML。

将业务对象转换为XML字符串（再次返回）而不是将业务对象转换为WCF契约对象（并重新启动），但它是否则类似

What is the proper way to handle polymorphic business objects in a WCF/SOAP world?

It seems to me that SOA and OOP are at odds with each other - to expose a clean WSDL you need concrete objects, typically not even utilizing inheritance. On the other hand, presumably in the underlying system, you'll want to follow proper OO design.

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?

解决方案

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?

Yes.

The way WCF serializes things ends up putting a lot of limitations on what you can and can't do with the contract objects. What you can't do ends up being "most anything useful".

I've found it makes things much clearer if you think of the WCF-contract objects as just a data transfer mechanism. Basically like strongly/statically typed XML.
Instead of converting your business object to an XML string (and back again), you convert your business object to a WCF-contract object (and back again), but it's otherwise similar

这篇关于WCF对象设计 - OOP vs SOA的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！